Internet Engineering Task Force (IETF) A. Johnston, Ed.
Request for Comments: 7463 Avaya
Updates: 3261, 4235 M. Soroushnejad, Ed.
Category: Standards Track V. Venkataramanan
ISSN: 2070-1721 Sylantro Systems Corp.
March 2015
Internet Engineering Task Force (IETF) A. Johnston, Ed.
Request for Comments: 7463 Avaya
Updates: 3261, 4235 M. Soroushnejad, Ed.
Category: Standards Track V. Venkataramanan
ISSN: 2070-1721 Sylantro Systems Corp.
March 2015
Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)
会话启动协议（SIP）记录地址（AOR）的共享外观
Abstract
摘要
This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP Private Branch Exchange (IPBX) offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group. This document discusses use cases, lists requirements, and defines extensions to implement this feature. This specification updates RFCs 3261 and 4235.
本文档描述了通常称为桥接线路外观（BLA）或多线路外观（MLA）或共享呼叫/线路外观（SCA）的组电话功能的要求和实现。当使用会话启动协议（SIP）实现时，它被称为记录地址（AOR）的共享外观，因为SIP没有行的概念。此功能通常在IP Centrex服务和IP专用分支交换机（IPBX）产品中提供，并且可能在业务环境中使用的SIP IP电话和SIP功能服务器上实现。此功能允许多个用户代理（UAs）共享一个公共AOR，了解组中其他UAs拨打和接收的呼叫，以及接听或加入组内的呼叫。本文档讨论用例，列出需求，并定义实现此功能的扩展。本规范更新了RFCs 3261和4235。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7463.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7463.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 5
3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 6
3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements and Implementation . . . . . . . . . . . . . . . 6
4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 8
5. Normative Description . . . . . . . . . . . . . . . . . . . . 10
5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Shared Appearance Dialog Package Extensions . . . . . . . 11
5.2.1. The <appearance> Element . . . . . . . . . . . . . . 11
5.2.2. The <exclusive> Element . . . . . . . . . . . . . . . 12
5.2.3. The <joined-dialog> Element . . . . . . . . . . . . . 12
5.2.4. The <replaced-dialog> Element . . . . . . . . . . . . 13
5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 13
5.3.1. Appearance Numbers and Call Context . . . . . . . . . 16
5.3.2. Appearance Numbers and Call Control . . . . . . . . . 17
5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 18
5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 18
6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 21
7. Alert-Info Appearance Parameter Definition . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 5
3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 6
3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements and Implementation . . . . . . . . . . . . . . . 6
4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 8
5. Normative Description . . . . . . . . . . . . . . . . . . . . 10
5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Shared Appearance Dialog Package Extensions . . . . . . . 11
5.2.1. The <appearance> Element . . . . . . . . . . . . . . 11
5.2.2. The <exclusive> Element . . . . . . . . . . . . . . . 12
5.2.3. The <joined-dialog> Element . . . . . . . . . . . . . 12
5.2.4. The <replaced-dialog> Element . . . . . . . . . . . . 13
5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 13
5.3.1. Appearance Numbers and Call Context . . . . . . . . . 16
5.3.2. Appearance Numbers and Call Control . . . . . . . . . 17
5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 18
5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 18
6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 21
7. Alert-Info Appearance Parameter Definition . . . . . . . . . 23
8. User Interface Considerations . . . . . . . . . . . . . . . . 24
8.1. Appearance Number Rendering . . . . . . . . . . . . . . . 24
8.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 24
8.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 24
8.1.3. Shared Appearance UAs with Fixed Appearance Number . 25
8.1.4. Shared Appearance UAs with Variable Appearance
Numbers . . . . . . . . . . . . . . . . . . . . . . . 25
8.1.5. Example User Interface Issues . . . . . . . . . . . . 25
8.2. Call State Rendering . . . . . . . . . . . . . . . . . . 26
9. Interoperability with Non-shared Appearance UAs . . . . . . . 26
9.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 26
9.2. Appearance Release . . . . . . . . . . . . . . . . . . . 27
9.3. UAs Supporting Dialog Events but Not Shared Appearance . 27
10. Provisioning Considerations . . . . . . . . . . . . . . . . . 27
11. Example Message Flows . . . . . . . . . . . . . . . . . . . . 28
11.1. Registration and Subscription . . . . . . . . . . . . . 28
11.2. Appearance Selection for Incoming Call . . . . . . . . . 32
11.3. Outgoing Call without Appearance Seizure . . . . . . . . 35
11.4. Outgoing Call with Appearance Seizure . . . . . . . . . 38
11.5. Outgoing Call without Using an Appearance Number . . . . 42
11.6. Appearance Release . . . . . . . . . . . . . . . . . . . 44
11.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . 45
11.8. Call between UAs within the Group . . . . . . . . . . . 50
11.9. Consultation Hold with Appearances . . . . . . . . . . . 52
11.10. Joining or Bridging an Appearance . . . . . . . . . . . 55
11.11. Loss of Appearance during Allocation . . . . . . . . . . 58
11.12. Appearance Seizure Contention Race Condition . . . . . . 59
11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 60
11.14. Appearance Pickup Race Condition Failure . . . . . . . . 62
11.15. Appearance Seizure Incoming/Outgoing Contention Race
Condition . . . . . . . . . . . . . . . . . . . . . . . 65
12. Security Considerations . . . . . . . . . . . . . . . . . . . 66
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
13.1. SIP Event Header Field Parameter: shared . . . . . . . . 67
13.2. SIP Alert-Info Header Field Parameter: appearance . . . 68
13.3. URN Sub-Namespace Registration: sa-dialog-info . . . . . 68
13.4. XML Schema Registration . . . . . . . . . . . . . . . . 68
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 69
14.1. Normative References . . . . . . . . . . . . . . . . . . 69
14.2. Informative References . . . . . . . . . . . . . . . . . 70
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71
8. User Interface Considerations . . . . . . . . . . . . . . . . 24
8.1. Appearance Number Rendering . . . . . . . . . . . . . . . 24
8.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 24
8.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 24
8.1.3. Shared Appearance UAs with Fixed Appearance Number . 25
8.1.4. Shared Appearance UAs with Variable Appearance
Numbers . . . . . . . . . . . . . . . . . . . . . . . 25
8.1.5. Example User Interface Issues . . . . . . . . . . . . 25
8.2. Call State Rendering . . . . . . . . . . . . . . . . . . 26
9. Interoperability with Non-shared Appearance UAs . . . . . . . 26
9.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 26
9.2. Appearance Release . . . . . . . . . . . . . . . . . . . 27
9.3. UAs Supporting Dialog Events but Not Shared Appearance . 27
10. Provisioning Considerations . . . . . . . . . . . . . . . . . 27
11. Example Message Flows . . . . . . . . . . . . . . . . . . . . 28
11.1. Registration and Subscription . . . . . . . . . . . . . 28
11.2. Appearance Selection for Incoming Call . . . . . . . . . 32
11.3. Outgoing Call without Appearance Seizure . . . . . . . . 35
11.4. Outgoing Call with Appearance Seizure . . . . . . . . . 38
11.5. Outgoing Call without Using an Appearance Number . . . . 42
11.6. Appearance Release . . . . . . . . . . . . . . . . . . . 44
11.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . 45
11.8. Call between UAs within the Group . . . . . . . . . . . 50
11.9. Consultation Hold with Appearances . . . . . . . . . . . 52
11.10. Joining or Bridging an Appearance . . . . . . . . . . . 55
11.11. Loss of Appearance during Allocation . . . . . . . . . . 58
11.12. Appearance Seizure Contention Race Condition . . . . . . 59
11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 60
11.14. Appearance Pickup Race Condition Failure . . . . . . . . 62
11.15. Appearance Seizure Incoming/Outgoing Contention Race
Condition . . . . . . . . . . . . . . . . . . . . . . . 65
12. Security Considerations . . . . . . . . . . . . . . . . . . . 66
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
13.1. SIP Event Header Field Parameter: shared . . . . . . . . 67
13.2. SIP Alert-Info Header Field Parameter: appearance . . . 68
13.3. URN Sub-Namespace Registration: sa-dialog-info . . . . . 68
13.4. XML Schema Registration . . . . . . . . . . . . . . . . 68
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 69
14.1. Normative References . . . . . . . . . . . . . . . . . . 69
14.2. Informative References . . . . . . . . . . . . . . . . . 70
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71
The feature and functionality requirements for SIP user agents (UAs) supporting business telephony applications differ greatly from basic SIP UAs, both in terms of services and end-user experience. In
支持业务电话应用程序的SIP用户代理（UAs）的特性和功能要求与基本SIP UAs在服务和最终用户体验方面有很大不同。在里面
addition to basic SIP support [RFC3261], many of the services in a business environment require the support for SIP extensions such as REFER [RFC3515], SUBSCRIBE/NOTIFY [RFC6665], PUBLISH [RFC3903], the SIP Replaces [RFC3891], and Join [RFC3911] header fields, etc. Many of the popular business services have been documented in the SIP Service Examples [RFC5359].
除了基本的SIP支持[RFC3261]之外，业务环境中的许多服务都需要对SIP扩展的支持，如参考[RFC3515]、订阅/通知[RFC6665]、发布[RFC3903]、SIP替换[RFC3891]和加入[RFC3911]头字段，许多流行的业务服务已记录在SIP服务示例[RFC5359]中。
This specification details a method for implementing a group telephony feature known variously in telephony as Bridged Line Appearance (BLA) or Multiple Line Appearances (MLA), one of the more popular advanced features expected of SIP IP telephony devices in a business environment. Other names for this feature include Shared Call/Line Appearance (SCA), Shared Call Status and Multiple Call Appearance (MCA). A variant of this feature is known as Single Line Extension.
本规范详细说明了一种实现组电话功能的方法，该组电话功能在电话技术中被称为桥接线路外观（BLA）或多线路外观（MLA），这是业务环境中SIP IP电话设备预期的更流行的高级功能之一。此功能的其他名称包括共享呼叫/线路外观（SCA）、共享呼叫状态和多呼叫外观（MCA）。此功能的一个变体称为单线扩展。
This document looks at how this feature can be implemented using standard SIP [RFC3261] in conjunction with SIP events [RFC6665] and publication [RFC3903] (carrying the SIP dialog state event package [RFC4235]) for exchanging status among UAs.
本文档介绍了如何使用标准SIP[RFC3261]结合SIP事件[RFC6665]和出版物[RFC3903]（携带SIP对话框状态事件包[RFC4235]）来实现此功能，以便在UAs之间交换状态。
In traditional telephony, the line is physical. A common scenario in telephony is for a number of business telephones to share a single or a small number of lines. The sharing or appearance of these lines between a number of phones is what gives this feature its name. A common scenario in SIP is for a number of business telephones to share a single or a small number of Address of Record (AOR) URIs.
在传统电话中，线路是物理的。电话技术中的一个常见场景是多部商用电话共用一条或少量线路。这些线路在多部手机之间的共享或外观是这一功能得名的原因。SIP中的一个常见场景是多个商用电话共享一个或少量的记录地址（AOR）URI。
In addition, an AOR can have multiple appearances on a single UA in terms of the user interface. The appearance number relates to the user interface for the telephone; typically, each appearance of an AOR has a visual display (lamp that can change color or blink or a screen icon) and a button (used to select the appearance) where each appearance number is associated with a different dialog to/from the AOR. The telephony concept of line appearance is still relevant to SIP due to the user interface considerations. It is important to keep the appearance number construct because:
此外，就用户界面而言，AOR可以在单个UA上有多个外观。外观编号与电话的用户界面有关；通常，AOR的每个外观都有一个视觉显示（可以改变颜色或闪烁的灯或屏幕图标）和一个按钮（用于选择外观），其中每个外观编号与AOR之间的不同对话框相关联。由于用户界面的考虑，线路外观的电话概念仍然与SIP相关。保持外观编号结构很重要，因为：
1. Human users are used to the concept and will expect it in replacement systems (e.g., an overhead page announcement says "Joe pickup line 3").
1. 人类用户已经习惯了这一概念，并期望在替换系统中使用它（例如，一个开销页面公告称“Joe Picking line 3”）。
2. It is a useful structure for user interface representation.
2. 它是用户界面表示的有用结构。
The purpose of the appearance number is to identify active calls to facilitate sharing between users (e.g., passing a call from one user to another). If a telephone has enough buttons/lamps, the appearance number could be the positional sequence number of the button. If
外观号码的目的是识别活动呼叫，以促进用户之间的共享（例如，将呼叫从一个用户传递到另一个用户）。如果电话有足够的按钮/灯，则外观编号可以是按钮的位置序列号。如果
not, it may still be desirable to present the call state, but the appearance number should be displayed so that users know which call, for example, is on hold on which key.
不是，可能仍然希望显示呼叫状态，但是应该显示外观号码，以便用户知道哪个呼叫（例如，哪个键处于等待状态）。
In this document, except for the usage scenarios in the next section, we will use the term "appearance" rather than "line appearance" since SIP does not have the concept of lines. Note that this does not mean that a conventional telephony user interface (lamps and buttons) must be used: implementations may use another metaphor as long as the appearance number is readily apparent to the user. Each AOR has a separate appearance numbering space. As a result, a given UA user interface may have multiple occurrences of the same appearance number, but they will be for different AORs.
在本文档中，除了下一节中的使用场景外，我们将使用术语“外观”而不是“线路外观”，因为SIP没有线路的概念。注意，这并不意味着必须使用传统的电话用户界面（灯和按钮）：实现可以使用另一种隐喻，只要外观编号对用户来说是显而易见的。每个AOR都有一个单独的外观编号空间。因此，给定的UA用户界面可能会多次出现相同的外观编号，但它们将用于不同的AOR。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant mechanisms.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释，并指明合规机制的要求级别。
The following examples are common applications of the shared appearances feature and are mentioned here as informative use cases. All these example usages can be supported by the shared appearances feature described in this document. The main differences relate to the user interface considerations of the device.
以下示例是共享外观功能的常见应用程序，在这里作为信息性用例介绍。本文档中描述的共享外观功能可以支持所有这些示例用法。主要差异与设备的用户界面考虑因素有关。
The appearances on the executive's UA also appear on the assistant's UA. The assistant may answer incoming calls to the executive and then place the call on hold for the executive to pick up. The assistant can always see the state of all calls on the executive's UA.
高管的UA上的出现也出现在助理的UA上。助理可以接听行政人员的来电，然后将电话挂起，让行政人员接听。助理可以随时查看主管UA上所有呼叫的状态。
Users with similar business needs or tasks can be assigned to specific groups and share an AOR. For example, an IT department staff of five might answer a help line that has three appearances on each phone in the IT work area. A call answered on one phone can be put on hold and picked up on another phone. A shout or an IM to another staff member can result in them taking over a call on a particular appearance. Another phone can request to be added/joined/ bridged to an existing appearance resulting in a conference call.
具有类似业务需求或任务的用户可以分配到特定组并共享AOR。例如，一名五人的IT部门员工可能会接听一条在IT工作区的每部电话上出现三次的帮助热线。在一部电话上接听的电话可以挂起，在另一部电话上接听。对另一名员工的喊叫或即时消息可能会导致他们在某个特定的场合接电话。另一部手机可以请求添加/加入/桥接到现有外观，从而形成电话会议。
In this scenario, incoming calls are offered to a group of UAs. When one answers, the other UAs are informed. If another UA in the group seizes the line (i.e., goes off-hook), it is immediately bridged or joined in with the call. This mimics the way residential telephone extensions usually operate.
在此场景中，传入呼叫提供给一组UAs。当一个回答时，会通知其他UAs。如果组中的另一个UA占用该线路（即脱钩），则该线路将立即桥接或加入呼叫。这模仿了住宅电话分机通常的工作方式。
A user is on a call on one UA and wishes to change devices and continue the call on another UA. They place the call on hold, note the appearance number of the call, then walk to another UA. They are able to identify the same appearance number on the other UA, pick up the call, and continue the conversation.
用户正在一个UA上通话，希望更换设备并在另一个UA上继续通话。他们将呼叫挂起，记下呼叫的出现号码，然后走到另一个UA。他们能够在另一个UA上识别相同的外观号码，接听电话并继续对话。
The next section details the requirements and discusses the implementation of the shared appearances feature.
下一节将详细介绍需求，并讨论共享外观功能的实现。
The basic requirements of the shared appearances feature can be summarized as follows:
共享外观功能的基本要求可概括如下：
REQ-1: Incoming calls to the AOR must be offered to a group of UAs and can be answered by any of them.
REQ-1：AOR的传入呼叫必须提供给一组UAs，并且可以由其中任何一个UAs应答。
REQ-2: Each UA in the group must be able to learn the call status of the others in the group for the purpose of rendering this information to the user.
REQ-2：为了向用户提供此信息，组中的每个UA必须能够了解组中其他UA的呼叫状态。
REQ-3: A UA must be able to join (also called bridge or conference together) or pick up (take) an active call of another UA in the group in a secure way.
REQ-3：UA必须能够以安全的方式加入（也称为桥接或会议）或接听（接听）组中另一UA的活动呼叫。
REQ-4: The mechanism should require the minimal amount of configuration. UAs registering against the group AOR should be able to participate in the shared appearance group without manual configuration of group members.
REQ-4：该机制应要求最少的配置量。针对组AOR注册的UAs应能够参与共享外观组，而无需手动配置组成员。
REQ-5: The mechanism must scale for large numbers of appearances and large numbers of UAs without introducing excessive messaging traffic.
REQ-5：该机制必须在不引入过多消息通信量的情况下，针对大量的外观和大量的UAs进行扩展。
REQ-6: Each call or session (incoming or outgoing) should be assigned a common "appearance" number from a managed pool
REQ-6：应为每个呼叫或会话（传入或传出）分配一个来自托管池的公共“外观”号码
administered for the AOR group. Once the session has terminated, the appearance number is released back into the pool and can be reused by another incoming or outgoing session.
为AOR组管理。会话终止后，外观号将释放回池中，并可由另一个传入或传出会话重用。
REQ-7: Each UA in the group must be able to learn the status of all appearances of the group.
REQ-7：组中的每个UA必须能够了解组中所有外观的状态。
REQ-8: There must be mechanisms to resolve appearance contention among the UAs in the group. Contention in this context means an appearance number being associated with multiple dialogs that are not mixed or otherwise associated.
REQ-8：必须有解决组中UAs之间外观争用的机制。此上下文中的争用表示一个外观编号与多个未混合或以其他方式关联的对话框相关联。
REQ-9: The mechanism must allow all UAs receiving an incoming session request to utilize the same appearance number at the time of alerting.
REQ-9：该机制必须允许所有接收到传入会话请求的UAs在发出警报时使用相同的外观号。
REQ-10: The mechanism must have a way of reconstructing appearance state after an outage that does not result in excessive traffic and processing.
REQ-10：该机制必须能够在中断后重建外观状态，而不会导致过多的通信量和处理。
REQ-11: The mechanism must have backwards compatibility such that a UA that is unaware of the feature can still register against the group AOR and make and receive calls.
REQ-11：该机制必须具有向后兼容性，以便不知道该功能的UA仍然可以针对组AOR进行注册，并拨打和接听电话。
REQ-12: The mechanism must not allow UAs outside the group to select, seize, or manipulate appearance numbers.
REQ-12：机构不得允许组外的UAs选择、扣押或操纵外观编号。
REQ-13: For privacy reasons, there must be a mechanism so that appearance information is not leaked outside the group of UAs (e.g., "So who do you have on line 1?").
REQ-13：出于隐私原因，必须有一种机制，以确保外观信息不会泄漏到UAs组之外（例如，“那么，第1行有谁？”）。
REQ-14: The mechanism must support a way for UAs to request exclusivity on a line appearance. Exclusivity means that the UA requesting it desires a private conversation with the external party and other UAs must not be allowed to join or take the call. Exclusivity may be requested at the start of an incoming or outgoing session or during the session. An exclusivity request may be accepted or rejected by the entity providing the shared appearance service. Therefore, the mechanism must provide a way of communicating the result back to the requester UA.
REQ-14：该机制必须支持UAs请求线路外观排他性的方式。排他性意味着请求其与外部方进行私人对话的UA，不得允许其他UAs加入或接听电话。排他性可在传入或传出会话开始时或会话期间请求。提供共享外观服务的实体可以接受或拒绝排他性请求。因此，该机制必须提供一种将结果传回请求者UA的方式。
REQ-15: The mechanism should support a way for a UA to seize a particular appearance number for outgoing requests prior to sending the actual request. This is often called seizure.
REQ-15：该机制应支持UA在发送实际请求之前获取传出请求的特定外观号的方法。这通常被称为癫痫。
REQ-16: The mechanism should support a way for a UA to seize a particular appearance number and also send the request at the same time. This is needed when an automatic ringdown feature (a telephone configured to immediately dial a phone number when it goes off-hook) is combined with shared appearances. In this case, seizing the line is integrated with dialing.
REQ-16：该机制应支持UA获取特定外观编号的方式，并同时发送请求。当自动响铃功能（配置为在挂机时立即拨打电话号码的电话）与共享外观相结合时，这是必需的。在这种情况下，占线与拨号集成在一起。
This section non-normatively discusses the implementation of the shared appearances feature. The normative description is in Section 5. Many of the requirements for this service can be met using standard SIP mechanisms such as:
本节非规范性地讨论共享外观功能的实现。规范性说明见第5节。使用标准SIP机制可以满足此服务的许多要求，例如：
o A SIP Forking Proxy and Registrar/Location Service meets REQ-1.
o SIP分叉代理和注册器/位置服务符合REQ-1。
o The SIP Dialog Package meets REQ-2.
o SIP对话包符合REQ-2的要求。
o The combination of the SIP Replaces and Join header fields meets REQ-3.
o SIP替换和连接头字段的组合符合REQ-3。
o The use of a State Agent for the Dialog Package meets REQ-4 and REQ-5.
o 对话框包使用状态代理符合REQ-4和REQ-5。
REQ-6 suggests the need for an entity that manages the appearance resource. Just as conferencing systems commonly have a single point of control, known as a focus, a shared appearance group has a single point of control of the appearance shared resource. This is defined as an Appearance Agent for a group. While an Appearance Agent can be part of a centralized server, it could also be co-resident in a member UA that has taken on this functionality for a group. The Appearance Agent knows or is able to determine the dialog state of all members of the group.
REQ-6建议需要一个实体来管理外观资源。正如会议系统通常有一个称为焦点的单点控制一样，共享外观组也有一个外观共享资源的单点控制。这被定义为组的外观代理。虽然外观代理可以是集中式服务器的一部分，但它也可以共同驻留在为组承担此功能的成员UA中。外观代理知道或能够确定组中所有成员的对话框状态。
While the appearance resource could be managed cooperatively by a group of UAs without any central control, this is outside the scope of this document. It is also possible that the Appearance Agent logic could be distributed in all UAs in the group. For example, rules that govern assigning appearance numbers for incoming requests (e.g., lowest available appearance number) and rules for contention handling (e.g., when two UAs request the use of the same appearance number, hash dialog identifiers and compare with the lowest hash winning) would need to be defined and implemented.
虽然外观资源可以由一组无需任何中央控制的UAs协同管理，但这不在本文档的范围之内。外观代理逻辑也可能分布在组中的所有UAs中。例如，需要定义和实现控制为传入请求分配外观编号的规则（例如，最低可用外观编号）和争用处理规则（例如，当两个UAs请求使用相同的外观编号、哈希对话框标识符并与最低哈希值进行比较时）。
To best meet REQ-9, the appearance number for an incoming INVITE needs to be contained in the INVITE, in addition to being delivered in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or
为了最好地满足REQ-9的要求，除了在对话框包NOTIFY中传递外，传入INVITE的外观号还需要包含在INVITE中。否则，如果通知延迟或
lost, a UA in the group might receive an incoming INVITE but might not know which appearance number to render during alerting.
丢失，组中的UA可能会收到传入的邀请，但可能不知道在警报期间呈现哪个外观编号。
This specification defines an extension parameter, which is normatively defined in Section 7, for the Alert-Info header field in RFC 3261 to carry the appearance number:
本规范为RFC 3261中的警报信息标题字段定义了一个扩展参数，该参数在第7节中有标准定义，用于携带外观编号：
Alert-Info: <urn:alert:service:normal>;appearance=1
Alert-Info: <urn:alert:service:normal>;appearance=1
The following list describes the operation of the shared appearances feature.
下表介绍了共享外观功能的操作。
1. A UA is configured with the AOR of a shared appearance group. It registers against the AOR, then attempts a dialog state subscription to the AOR. If the subscription fails, loops back to itself, or returns an error, it knows there is no State Agent and, hence, no Appearance Agent and this feature is not implemented.
1. UA配置有共享外观组的AOR。它针对AOR注册，然后尝试对AOR进行对话框状态订阅。如果订阅失败、返回自身或返回错误，则它知道不存在状态代理，因此不存在外观代理，并且此功能未实现。
2. If the subscription receives a 200 OK, the UA knows there is a State Agent and that the feature is implemented. The UA then follows the steps in this list.
2. 如果订阅收到200 OK，UA知道存在状态代理，并且该功能已实现。UA随后遵循此列表中的步骤。
3. Information learned about the dialog state of other UAs in the group is rendered to the user.
3. 了解到的有关组中其他UAs的对话框状态的信息将呈现给用户。
4. Incoming calls are forked to all UAs in the group, and any may answer. UAs receive the appearance number to use in rendering the incoming call in a NOTIFY from the Appearance Agent and in the INVITE itself. The UA will also receive a notification if the call is answered by another UA in the group so this information can be rendered to the user.
4. 传入呼叫被转接到组中的所有UAs，任何UAs都可以接听。UAs接收外观号码，用于在外观代理的通知和邀请中呈现传入呼叫。如果通话由组中的另一个UA应答，UA也将收到通知，以便将此信息提供给用户。
5. For outgoing calls, the operation depends on the implementation. If the user seizes a particular appearance number for the call, the UA publishes the trying state dialog information with the desired appearance number and waits for a 2xx response before sending the INVITE.
5. 对于传出呼叫，操作取决于实现。如果用户捕获了呼叫的特定外观号码，UA将发布带有所需外观号码的尝试状态对话框信息，并在发送邀请之前等待2xx响应。
6. For outgoing calls, if the user does not seize a particular appearance or does not care, the INVITE can be sent immediately, and the appearance number learned as the call progresses from a notification from the Appearance Agent.
6. 对于传出呼叫，如果用户没有抓住某个特定的外观或不在乎，则可以立即发送邀请，并在呼叫过程中从外观代理的通知中学习外观号码。
7. For outgoing calls, if the user does not want an appearance number assigned (such as during a consultation call or if a UA is fetching 'service media' such as music on hold [RFC7088]), the UA
7. 对于传出呼叫，如果用户不希望分配外观号码（例如在咨询呼叫期间，或者如果UA正在获取“服务媒体”，例如保留音乐[RFC7088]），则UA
also publishes prior to sending the INVITE but does not include an appearance number in the publication.
也在发送邀请之前发布，但不在发布中包含外观编号。
8. Established calls within the group may be joined (bridged) or taken (picked) by another UA. Information in the dialog package notifications can be used to construct Join or Replaces header fields. Since the same appearance number is used for these types of operations, this information is published prior to sending the INVITE Join or INVITE Replaces.
8. 组内已建立的呼叫可由另一UA加入（桥接）或接听（拾取）。对话框包通知中的信息可用于构造联接或替换标头字段。由于这些类型的操作使用相同的外观编号，因此在发送邀请加入或邀请替换之前会发布此信息。
9. The Appearance Agent may not have direct access to the complete dialog state of some or all of the UAs in the group. If this is the case, the Appearance Agent will subscribe to the dialog state of individual UAs in the group to obtain this information. In any case, the Appearance Agent will send normal notifications (via the subscriptions established by the UAs in step 1) every time the aggregate dialog state of the AOR changes, including when calls are placed, answered, placed on and off hold, and hung up.
9. 外观代理可能无法直接访问组中某些或所有UAs的完整对话状态。如果是这种情况，则外观代理将订阅组中各个UAs的对话状态以获取此信息。在任何情况下，每次AOR的聚合对话框状态发生变化时，外观代理都会发送正常通知（通过UAs在步骤1中建立的订阅），包括拨打、接听、挂断和挂断呼叫时。
This section normatively describes the shared appearances feature extensions. The following definitions are used throughout this document:
本节规范性地描述了共享外观功能扩展。本文件中使用了以下定义：
Appearance number: An appearance number is a positive integer associated with one or more dialogs of an AOR. Appearance numbers are managed by an Appearance Agent and displayed and rendered to the user by UAs that support this specification. When an appearance number is assigned or requested, generally the assigned number is the smallest positive integer that is not currently assigned as an appearance number to a dialog for this AOR. This specification does not define an upper limit on appearance numbers; however, using appearance numbers that are not easily represented using common integer representations is likely to cause failures.
外观编号：外观编号是与AOR的一个或多个对话框关联的正整数。外观编号由外观代理管理，并由支持此规范的UAs显示和呈现给用户。当分配或请求外观编号时，通常分配的编号是当前未作为外观编号分配给此AOR对话框的最小正整数。本规范未规定外观编号的上限；但是，使用不易用通用整数表示法表示的外观编号可能会导致失败。
Seizing: An appearance can be reserved prior to a call being placed by seizing the appearance. An appearance can be seized by communicating an artificial state of "trying" prior to actually initiating a dialog (i.e., sending the INVITE), in order to appear as if it were already initiating a dialog.
抢占：通过抢占外观，可以在拨打电话之前保留外观。通过在实际启动对话（即发送邀请）之前传达“尝试”的人工状态，可以捕获外观，以便看起来好像它已经启动了对话。
Selecting (or Not-Seizing): An appearance is merely selected (i.e., not seized) if there is no such communication of artificial state of "trying" prior to initiating a dialog: i.e., the state is
选择（或不捕捉）：如果在启动对话框之前没有“尝试”的人工状态的通信，则仅选择（即，未捕捉）外观：即，状态为
communicated when the dialog is actually initiated. The appearance number is learned after the INVITE is sent.
对话实际启动时进行沟通。发送邀请后，将学习外观编号。
A complete system to implement this feature consists of:
实现此功能的完整系统包括：
1. UAs that support publications, subscriptions, and notifications for the SIP dialog event package and the shared appearance dialog package extensions and behavior.
1. 支持SIP对话事件包和共享外观对话包扩展和行为的发布、订阅和通知的UAs。
2. An Appearance Agent consisting of a State Agent for the dialog event package that implements an Event State Compositor (ESC) and the shared appearance dialog package extensions and behavior. The Appearance Agent also has logic for assigning and releasing appearance numbers and resolving appearance number contention.
2. 一种外观代理，由对话框事件包的状态代理组成，该对话框事件包实现事件状态合成器（ESC）和共享外观对话框包扩展和行为。外观代理还具有分配和释放外观编号以及解决外观编号争用的逻辑。
3. A forking proxy server that can communicate with the State Agent.
3. 可以与状态代理通信的分叉代理服务器。
4. A registrar that supports the registration event package.
4. 支持注册事件包的注册器。
The behavior of these elements is described normatively in the following sections after the definitions of the dialog package extensions.
这些元素的行为在对话框包扩展定义之后的以下部分中进行了规范性描述。
This specification defines four new elements as extensions to the SIP Dialog Event package [RFC4235]. The schema is defined in Section 6. The elements are <appearance>, <exclusive>, <joined-dialog>, and <replaced-dialog>, which are sub-elements of the <dialog> element.
本规范定义了四个新元素作为SIP对话事件包[RFC4235]的扩展。模式在第6节中定义。这些元素是<appearance>、<exclusive>、<joined dialog>和<replaced dialog>，它们是<dialog>元素的子元素。
The <appearance> element, a child of the <dialog> element, is used to convey the appearance number of the dialog described by the parent <dialog> element. When sent by a UA in a PUBLISH with parent <dialog> with state attribute "trying" to the Appearance Agent, the UA is requesting assignment of the given appearance number to the current or future dialog with the given dialog identifiers. When an <appearance> element is sent by the Appearance Agent in a NOTIFY, it indicates that the appearance number has been assigned to the specified dialog.
<earance>元素是<dialog>元素的子元素，用于传递父<dialog>元素描述的对话框的外观编号。当UA在状态属性为“trying”的具有父级<dialog>的发布中发送给外观代理时，UA请求将给定的外观编号分配给具有给定对话框标识符的当前或未来对话框。当外观代理在通知中发送<外观>元素时，它表示外观编号已分配给指定的对话框。
Note that a <dialog-info> element describes the contained dialogs from the point of view of the UA (named by the "entity" attribute), regardless of whether the containing request is sent by the UA or the Appearance Agent. In particular, if the UA sent a request within the
请注意，<dialog info>元素从UA的角度（由“entity”属性命名）描述包含的对话框，而不管包含的请求是由UA还是外观代理发送的。特别是，如果UA在
described dialog, the To header field URI would match the <remote> <identity> value and the to-tag parameter would match the remote-tag attribute. Similarly, the From header field URI would match the <local> <identity> value and the from-tag parameter would match the local-tag attribute.
在描述的对话框中，To header字段URI将与<remote><identity>值匹配，而To-tag参数将与remote-tag属性匹配。类似地，From头字段URI将与<local><identity>值匹配，From标记参数将与local标记属性匹配。
The <exclusive> element, a child of the <dialog> element, is a boolean, which, when true, indicates that the UA is not willing to accept an INVITE with a Join or Replaces header field targeted to the dialog described by the <dialog> element that is the parent of the <exclusive> element. For example, some shared appearance systems only allow call pickup when the call is on hold. In this case, the <exclusive> element should be set to "false" when the call is held and "true" when the call is not held, rather than having the "exclusive" value implied by the hold state.
<dialog>元素的子元素<exclusive>元素是一个布尔值，如果为true，则表示UA不愿意接受带有连接的邀请，或者替换作为<exclusive>元素父元素的<dialog>元素所描述的对话框的目标头字段。例如，某些共享外观系统仅允许在呼叫处于保留状态时接听呼叫。在这种情况下，<exclusive>元素应该在呼叫保持时设置为“false”，在呼叫未保持时设置为“true”，而不是保持状态所隐含的“exclusive”值。
It is important to note that this element is a hint. In order to prevent another UA from taking or joining a call, a UA can, in addition to setting the <exclusive> tag, not report full dialog information to the Appearance Agent. Not having the full dialog information (Call-ID, remote-tag, and local-tag) prevents another UA from constructing a Join or Replaces header field. Although a UA may set <exclusive> to "true", the UA must still be ready to reject an INVITE Join relating to this dialog. If these dialog identifiers have already been shared with the Appearance Agent, the UA could send an INVITE Replaces to change them and then not report the new ones to the Appearance Agent.
需要注意的是，此元素是一个提示。为了防止另一UA接听或加入呼叫，UA除了设置<exclusive>标记外，还可以不向外观代理报告完整的对话信息。没有完整的对话框信息（呼叫ID、远程标记和本地标记）会阻止另一个UA构建连接或替换头字段。虽然UA可以将<exclusive>设置为“true”，但UA仍必须准备好拒绝与此对话框相关的邀请加入。如果这些对话框标识符已经与外观代理共享，UA可以发送一个INVITE Replaces来更改它们，然后不向外观代理报告新的标识符。
If the proxy knows which dialogs are marked exclusive, the proxy MAY enforce this exclusivity by rejecting INVITE Join and INVITE Replaces requests containing those dialog identifiers with a 403 (Forbidden) response.
如果代理知道哪些对话框被标记为独占，则代理可以通过拒绝INVITE Join和INVITE将包含这些对话框标识符的请求替换为403（禁止）响应来强制执行此独占性。
Note that exclusivity has nothing to do with appearance number selection or seizing -- instead, it is about call control operations that can be performed on a dialog.
请注意，排他性与外观号码的选择或捕捉无关——相反，它是关于可以在对话框上执行的呼叫控制操作。
If the <exclusive> element is not present, it is assumed to be false.
如果<exclusive>元素不存在，则假定它为false。
The <joined-dialog> element, a child of the <dialog> element, is used to convey dialog identifiers of any other dialogs that are joined (mixed or bridged) with the dialog. Only the UA that is the common endpoint of the mixed dialogs (and thus controlling the mixing operation) should include this element in publications to the
<joined dialog>元素是<dialog>元素的子元素，用于传递与该对话框连接（混合或桥接）的任何其他对话框的对话框标识符。只有作为混合对话框的公共端点（从而控制混合操作）的UA才应将此元素包含在到的发布中
Appearance Agent. Note that this element should still be used even when the Join header field was not used to join the dialogs. For example, two separate dialogs on a UA could be joined without any SIP call control operations. Joined dialogs will share the same appearance number.
外观代理。注意，即使Join header字段未用于加入对话框，也应使用此元素。例如，UA上的两个独立对话框可以在没有任何SIP呼叫控制操作的情况下连接。连接的对话框将共享相同的外观编号。
If the <joined-dialog> element is not present, it is assumed that the dialog is not joined or to be joined to any other dialog.
如果<joined dialog>元素不存在，则假定该对话框未连接或将连接到任何其他对话框。
The <replaced-dialog> element, a child of the <dialog> element, is used to convey dialog identifiers of any other dialogs that will be or have been replaced with this dialog. For example, a UA in the group picking up a call on another UA by sending an INVITE with Replaces would include this element for the replacing dialog. Replaced dialogs will share the same appearance number.
<replaced dialog>元素是<dialog>元素的子元素，用于传递将被或已被此对话框替换的任何其他对话框的对话框标识符。例如，组中的一个UA通过发送带有替换的邀请来接听另一个UA的电话，将在替换对话框中包含此元素。被替换的对话框将共享相同的外观编号。
If the <replaced-dialog> element is not present, it is assumed that the dialog has not replaced or is not to replace to any other dialog.
如果<replaced dialog>元素不存在，则假定该对话框未替换或不替换为任何其他对话框。
UAs that support the shared appearances feature use the dialog state package [RFC4235] with the shared appearance extensions and the 'shared' Event header field parameter defined in Section 13.
支持共享外观功能的UAs使用对话框状态包[RFC4235]以及第13节中定义的共享外观扩展和“共享”事件标题字段参数。
UAs use the dialog package extensions in Section 5.2 along with SUBSCRIBE [RFC6665], NOTIFY [RFC6665], and PUBLISH [RFC3903]. SUBSCRIBE, NOTIFY, and PUBLISH requests for the dialog event package include the 'shared' Event header field parameter as required by this specification.
UAs使用第5.2节中的对话框包扩展以及订阅[RFC6665]、通知[RFC6665]和发布[RFC3903]。对话框事件包的订阅、通知和发布请求包括本规范要求的“共享”事件标题字段参数。
The presence of the 'shared' Event header field parameter tells the Appearance Agent that the UA supports this specification.
“共享”事件头字段参数的存在告诉外观代理UA支持此规范。
Upon initialization, the UA MUST subscribe to the dialog event package of the AOR and refresh the subscription per the SIP Events Framework [RFC6665]. If the SUBSCRIBE request fails, then no Appearance Agent may be present and this feature is not active for this AOR. The UA MAY periodically retry the subscription to see if conditions have changed at intervals no shorter than four hours.
初始化时，UA必须订阅AOR的对话事件包，并根据SIP事件框架[RFC6665]刷新订阅。如果订阅请求失败，则可能不存在外观代理，并且此AOR的此功能不处于活动状态。UA可定期重试订阅，以查看条件是否以不少于四小时的间隔发生了变化。
Four hours was chosen to limit the subscription test to six per day per UA. Increasing this interval would reduce this failure traffic but take longer for a newly activated Appearance Agent to be discovered.
选择了四个小时，以将订阅测试限制为每个UA每天六个小时。增加此间隔将减少此故障通信量，但发现新激活的外观代理需要更长的时间。
UAs can also use the presence of the 'shared' Event header field parameter in NOTIFYs to discover the presence of an Appearance Agent for the AOR.
UAs还可以使用NOTIFY中的“共享”事件头字段参数来发现AOR是否存在外观代理。
UAs that implement the shared appearances feature, call pickup, joining, and bridging MUST support sending an INVITE with Replaces [RFC3891] or Join [RFC3911]. The User Agent Client (UAC) needs to include the to-tag and from-tag information in the Replaces or Join header so that the correct dialog will be matched by the User Agent Server (UAS) per the rules in RFCs 3891 and 3911.
实现共享外观功能、呼叫接听、加入和桥接的UAs必须支持通过替换[RFC3891]或加入[RFC3911]发送邀请。用户代理客户端（UAC）需要在Replaces或Join标头中包含to标记和from标记信息，以便用户代理服务器（UAS）根据RFCs 3891和3911中的规则匹配正确的对话框。
All UAs that implement the shared appearances feature and support INVITE MUST support receiving an INVITE with a Replaces [RFC3891] or a Join [RFC3911] header field.
所有实现共享外观功能并支持邀请的UAs必须支持接收带有替换[RFC3891]或加入[RFC3911]标题字段的邀请。
When publishing or notifying dialog package information, a UA includes the largest set of dialog identification available at the time of publication, with the exception that a UA may omit information if it wishes to prevent other UAs from joining or picking up a call. Dialog identification includes local and remote target URIs, call-id, to-tag, and from-tag. While this dialog identification information is optional in [RFC4235], it is essential in the shared appearances feature, allowing call control operations. When placing calls on hold, use the "+sip.rendering=no" feature tag to indicate this in dialog package notifications. Using the full SDP session description instead forces the endpoint to do a lot of extra parsing, unnecessarily complicating the code and inviting errors.
发布或通知对话框包信息时，UA包括发布时可用的最大一组对话框标识，除非UA希望阻止其他UA加入或接听呼叫，否则可能会忽略信息。对话框标识包括本地和远程目标URI、调用id、to标记和from标记。虽然此对话框标识信息在[RFC4235]中是可选的，但它在共享外观功能中是必不可少的，允许调用控制操作。将呼叫置于挂起状态时，请使用“+sip.rendering=no”功能标记在对话框包通知中指示此情况。相反，使用完整的SDP会话描述会迫使端点执行大量额外的解析，从而使代码变得不必要的复杂，并引发错误。
The accurate rendering of the idle/active/alerting/hold state of other UAs in the group is an important part of the shared appearances feature.
准确呈现组中其他UAs的空闲/活动/警报/保持状态是共享外观功能的重要组成部分。
A UA that does not need to seize a particular appearance number (or doesn't care) would just send an INVITE as normal to place an outbound call.
不需要获取特定外观号码（或不在乎）的UA只需像平常一样发送邀请即可拨打出站电话。
If the call is an emergency call, a UA MUST never wait for a confirmed seizure before sending an INVITE. Instead, the emergency call MUST proceed without waiting for the PUBLISH transaction.
如果呼叫是紧急呼叫，UA在发送邀请之前不得等待确认的癫痫发作。相反，紧急呼叫必须在不等待发布事务的情况下继续进行。
If a UA requires a particular appearance number, the a UA MUST send a dialog package PUBLISH request and wait for a 2xx response before sending the INVITE. This is required in the following situations:
如果UA需要特定的外观编号，则UA必须发送对话框包发布请求，并在发送邀请之前等待2xx响应。在以下情况下，这是必需的：
1. When the user seizes a particular appearance number for an outgoing call (e.g., seizing the appearance and going "off-hook", if the UA's user interface uses this metaphor).
1. 当用户抓住一个传出呼叫的特定外观号码时（例如，如果UA的用户界面使用这个比喻，抓住外观并“脱钩”）。
2. When the user has requested that an appearance number not be used for an outgoing call (i.e., during a consultation call, a 'service media' call such as for music on hold [RFC7088], or for a call not considered part of the shared appearance group).
2. 当用户请求外观号码不用于传出呼叫时（即，在咨询呼叫期间，“服务媒体”呼叫，例如用于等待音乐[RFC7088]，或用于不被视为共享外观组一部分的呼叫）。
3. When the user has selected to join (or bridge) an existing call.
3. 当用户选择加入（或桥接）现有呼叫时。
4. When the user has selected to replace (or take) an existing call.
4. 当用户选择替换（或接听）现有通话时。
Note that when a UA seizes an appearance prior to establishment of a dialog (numbers 1 and 2 in the above list), not all dialog information will be available. In particular, when a UA publishes an attempt to seize an appearance prior to knowing the destination URI, minimal or no dialog information may be available. For example, in some cases, only the local target URI for the call will be known: not any dialog information. If the From tag and Call-ID were not present in the initial PUBLISH, a new PUBLISH MUST be sent as soon as this information is available.
请注意，当UA在建立对话（上面列表中的数字1和2）之前捕获外观时，并非所有对话信息都可用。特别是，当UA在知道目标URI之前发布试图捕获外观的尝试时，可能会有最少或没有可用的对话框信息。例如，在某些情况下，只有调用的本地目标URI是已知的：而不是任何对话框信息。如果初始发布中不存在From标记和调用ID，则必须在该信息可用时立即发送新发布。
The first publication will cause the Appearance Agent to reserve the appearance number for this UA. If the publication does not have any dialog identifiers (e.g., Call-ID or local-tag), the Appearance Agent cannot assign the appearance number to a particular dialog of the UA until the second publication, which will contain some dialog identifiers.
第一次发布将导致外观代理保留此UA的外观编号。如果发布没有任何对话框标识符（例如，呼叫ID或本地标记），则在第二次发布之前，外观代理无法将外观编号分配给UA的特定对话框，该第二次发布将包含一些对话框标识符。
This publication state is refreshed as described in [RFC3903] during the early dialog state or the Appearance Agent may reassign the appearance number. Once the dialog has transitioned to the confirmed state, no publication refreshes are necessary.
此发布状态在早期对话框状态期间按照[RFC3903]中所述刷新，或者外观代理可以重新分配外观编号。对话框转换为确认状态后，无需刷新发布。
This specification assumes that the Appearance Agent has other means besides UA publication to learn about the state of UA dialogs. In this specification, PUBLISH is used to indicate desired and intended appearance number operations. Once a dialog transitions from early to confirmed, this role is over; hence, no publication refreshes are needed.
本规范假设外观代理除了UA发布之外还有其他方法来了解UA对话框的状态。在本规范中，发布用于指示所需和预期的外观编号操作。一旦对话从早期过渡到确认，这个角色就结束了；因此，不需要进行出版物刷新。
Appearance numbers are a shorthand label for active and pending dialogs related to an AOR. Many of the features and services built using this extension rely on the correct rendering of this information to the human user. In addition, the group nature of the feature means that the rendering must be similar between different vendors and different models. Failure to do so will greatly reduce the value and usefulness of these protocol extensions. In a correctly designed user interface for this feature, the appearances number for each active and pending dialog is explicitly (i.e., by appearance number) or implicitly (using a user interface metaphor
外观编号是与AOR相关的活动和挂起对话框的简写标签。使用此扩展构建的许多功能和服务依赖于向人类用户正确呈现这些信息。此外，该功能的组性质意味着不同供应商和不同模型之间的渲染必须相似。否则将大大降低这些协议扩展的价值和实用性。在为此功能正确设计的用户界面中，每个活动和挂起对话框的外观编号是显式的（即，通过外观编号）或隐式的（使用用户界面隐喻）
that makes the numbering and ordering clear to the user) rendered to the user. The far-end identity of each dialog (e.g., the remote party identity) is not a useful replacement for the appearance number. The state of each appearance is also to be rendered (idle, active, busy, joined, etc.). UAs can tell that a set of dialogs are joined (bridged or mixed) together by the presence of one or more <joined-dialog> elements containing other SIP dialog identifiers. Appearance numbers of dialogs can be learned by dialog package notifications containing the <appearance> element from the Appearance Agent or from the 'appearance' Alert-Info parameter in an incoming INVITE. Should they conflict, the dialog package notification takes precedence.
这使得编号和顺序对用户来说是清晰的）。每个对话框的远端标识（例如，远程方标识）不是外观编号的有用替代品。还将呈现每个外观的状态（空闲、活动、忙碌、已加入等）。UAs可以通过一个或多个包含其他SIP对话框标识符的<joined dialog>元素的存在来判断一组对话框是否连接在一起（桥接或混合）。对话框的外观编号可以通过包含来自外观代理的<Appearance>元素的对话框包通知或来自传入邀请中的'Appearance'警报信息参数了解。如果它们发生冲突，则以对话框包通知为准。
A user may select an appearance number but then abandon placing a call (go back on-hook). In this case, the UA frees up the appearance number by removing the event state with a PUBLISH as described in [RFC3903]. A failure to do this will require unnecessary operations by the Appearance Agent and tie up appearance numbers that could otherwise be used by other UAs in the shared appearance group.
用户可以选择一个外观号码，但随后放弃拨打电话（返回挂机）。在这种情况下，UA通过发布来删除事件状态，从而释放外观编号，如[RFC3903]中所述。否则，外观代理将需要执行不必要的操作，并绑定外观编号，否则共享外观组中的其他UAs可能会使用这些编号。
A UA SHOULD register against the AOR only if it is likely the UA will be answering incoming calls. If the UA is mainly going to be monitoring the status of the shared appearance group calls and picking or joining calls, the UA SHOULD only subscribe to the AOR and not register against the AOR. If a monitoring UA registers rather than just subscribing, it generates large amounts of unnecessary network traffic.
UA应仅在UA可能会接听来电的情况下根据AOR进行注册。如果UA主要监控共享外观组呼叫的状态以及拾取或加入呼叫，则UA应仅订阅AOR，而不针对AOR进行注册。如果监控UA注册而不仅仅是订阅，则会产生大量不必要的网络流量。
All subscribed UAs will receive dialog package NOTIFYs of trying state for incoming INVITEs.
所有订阅的UAs将收到对话框包NOTIFY，告知传入邀请的尝试状态。
A UA MUST NOT insert an 'appearance' parameter into an Alert-Info header field in an INVITE or other request.
UA不得在邀请或其他请求的警报信息标题字段中插入“外观”参数。
The Appearance Agent is solely responsible for doing this.
外观代理对此全权负责。
There are cases where two separate dialogs at a UA are not mixed but share the same 'context'. That is, they relate to each other and should not be treated the same as any other two dialogs within the group. One example of this is a 'consultation call' where a user puts an existing dialog on hold, then calls another user, before switching back to the original dialog. Another case, described below, occurs during transfer operations, where for a transient period, a UA is involved in dialogs with two other UAs, but the dialogs are related, and should not be treated as independent dialogs. These cases are best handled by not assigning an appearance
在某些情况下，UA中的两个独立对话框不是混合的，而是共享相同的“上下文”。也就是说，它们相互关联，不应与组中的任何其他两个对话框一样对待。这方面的一个例子是“咨询电话”，其中一个用户将一个现有的对话框挂起，然后在切换回原始对话框之前呼叫另一个用户。下面描述的另一种情况发生在传输操作期间，在过渡期间，UA与另外两个UA进行对话，但对话是相关的，不应被视为独立对话。最好通过不指定外观来处理这些情况
number to a newly created dialog when it shares a context with an existing dialog. But if the preexisting dialog is terminated, its appearance number should be reassigned to the newly created dialog.
新创建的对话框与现有对话框共享上下文时的编号。但是，如果先前存在的对话框终止，则应将其外观编号重新分配给新创建的对话框。
A UA that wants to place a call but does not have an appearance number assigned sends a PUBLISH before sending the INVITE. The PUBLISH does not have an 'appearance' element present, but it does have the 'shared' Event header field parameter present. If the Appearance Agent policy does not allow calls without an assigned appearance number, a 400 (Bad Request) response is sent by the Appearance Agent and the UA will republish either selecting/seizing an appearance number or send the INVITE without publishing, in which case the Appearance Agent will assign one.
想要拨打电话但未分配外观号码的UA在发送邀请之前发送发布。发布不存在“外观”元素，但存在“共享”事件标题字段参数。如果外观代理策略不允许没有分配外观号码的呼叫，则外观代理将发送400（错误请求）响应，UA将重新发布选择/捕获外观号码或发送邀请而不发布，在这种情况下，外观代理将分配一个。
Note that if an Appearance Agent rejects calls without an appearance number, certain operations such as consultation calls, transfer, and music on hold may be negatively impacted.
请注意，如果外观代理拒绝没有外观号码的呼叫，某些操作（如咨询呼叫、转接和音乐等待）可能会受到负面影响。
When an INVITE is generated to attempt to bridge or take a call (i.e., contains Join or Replaces with a dialog identifier of another dialog in the shared appearance group), the UA MUST first send a PUBLISH to the Appearance Agent. This PUBLISH will contain:
当生成邀请以尝试桥接或接听电话（即，包含加入或替换为共享外观组中另一个对话框的对话框标识符）时，UA必须首先向外观代理发送发布。本出版物将包括：
1. The appearance number of the joined or replaced call in the <appearance> element
1. <appearance>元素中已加入或已替换调用的外观编号
2. The dialog information from the Join header field in the <joined-dialog> element, if the dialog is being joined
2. 如果正在连接对话框，则来自<joined dialog>元素中的“连接头”字段的对话框信息
3. The dialog information from the Replaces header field in the <replaced-dialog> element, if the dialog is being replaced
3. 如果对话框正在被替换，则来自<replaced dialog>元素中Replaces header字段的对话框信息
Note that this information is provided to the Appearance Agent so that it can provide proper appearance assignment behavior. If the INVITE Join or Replaces was sent without publishing first, the Appearance Agent might assign a new appearance number to this INVITE, which would be a mistake. With Join, the publication has the <joined-dialog> element to prevent the Appearance Agent from generating a 400 (Bad Request) response due to the reuse of an appearance number. For Replaces, the purpose of the <replaced-dialog> is to prevent a race condition where the BYE could cause the appearance number to be released when it should stay with the replacing dialog.
请注意，此信息提供给外观代理，以便它能够提供正确的外观分配行为。如果邀请加入或替换在未首先发布的情况下发送，则外观代理可能会为此邀请分配新的外观编号，这将是一个错误。使用Join，发布具有<Join dialog>元素，以防止外观代理由于重用外观编号而生成400（错误请求）响应。对于替换，<replaced dialog>的目的是防止出现竞态情况，在竞态情况下，BYE可能导致外观编号在应与替换对话框保持一致时被释放。
During a transfer operation, it is important that the appearance number not change during the operation. Consider the example of Alice, a member of a shared appearance group, who is talking to Carol, who is outside the shared appearance group. Carol transfers Alice to David, who is also outside the shared appearance group. For example, if Alice is using appearance 3 for the session with Carol, the resulting session with David should also use appearance number 3. Otherwise, an appearance number change can cause a "jump" on the UI and confusion to the user. There are two possible scenarios using the terminology of RFC 5589: Alice is the transferee in any type of transfer (receives the REFER) or the transfer target in an attended transfer (receives the INVITE with Replaces).
在传输操作期间，外观编号在操作期间不得更改，这一点很重要。考虑一个共享外观组的成员爱丽丝的例子，他正在与共享外观组之外的凯罗尔交谈。卡罗尔把艾丽丝转给大卫，大卫也不在“共享外表”小组之内。例如，如果Alice在与Carol的会话中使用外观3，则与David的会话也应使用外观3。否则，外观编号的更改可能会导致用户界面上的“跳转”和用户的困惑。使用RFC 5589术语有两种可能的情况：Alice是任何类型转让中的受让人（接收转介）或有人参与转让中的转让目标（接收带替换的邀请）。
If Alice is the transferee, the triggered INVITE from the REFER is treated as a consultation call. Alice SHOULD publish requesting that the Appearance Agent not assign an appearance number for this INVITE. When the transfer completes, Alice SHOULD publish again to move the appearance number from the dialog with Carol to the dialog with David. If a PUBLISH is sent to move the appearance number, the publication MUST be sent prior to sending the BYE to Carol to avoid a race condition where the Appearance Agent reassigns the appearance number after seeing the BYE.
如果Alice是受让人，则来自REFER的触发邀请将被视为咨询电话。Alice应发布请求，要求外观代理不为此邀请分配外观编号。传输完成后，Alice应再次发布，以将外观编号从与Carol的对话移动到与David的对话。如果发送发布以移动外观编号，则必须在向Carol发送BYE之前发送发布，以避免出现竞态情况，即外观代理在看到BYE后重新分配外观编号。
If Alice is the target, the incoming INVITE will contain a Replaces header field. As a result, the Appearance Agent will have reused the appearance number of the dialog with Carol, and this appearance number will continue to be used after the dialog with Carol has been terminated.
如果Alice是目标，则传入的INVITE将包含一个Replaces头字段。因此，外观代理将重用与Carol的对话框的外观编号，并且在与Carol的对话框终止后，将继续使用此外观编号。
An Appearance Agent defined in this specification MUST implement a dialog package state agent for the UAs registered against the AOR. The Appearance Agent MUST support the appearance dialog package extensions defined in Section 5.2 and use the 'shared' Event header field parameter. The Appearance Agent MUST support publications and subscriptions for this event package.
本规范中定义的外观代理必须为根据AOR注册的UAs实现对话包状态代理。外观代理必须支持第5.2节中定义的外观对话框包扩展，并使用“共享”事件标题字段参数。外观代理必须支持此事件包的发布和订阅。
The Appearance Agent MUST have a way of discovering the state of all dialogs associated with the AOR. If this information is not available from a call stateful proxy or Back-to-Back User Agent (B2BUA), the Appearance Agent can use the registration event package [RFC3680] to learn of UAs associated with the AOR and subscribe to their dialog event state. An Appearance Agent can also subscribe to a UA's dialog event state in order to reconstruct state. As a result, the registrar MUST support the registration event package.
外观代理必须能够发现与AOR关联的所有对话框的状态。如果呼叫状态代理或背对背用户代理（B2BUA）无法提供此信息，则外观代理可以使用注册事件包[RFC3680]了解与AOR关联的UAs，并订阅其对话事件状态。外观代理还可以订阅UA的对话事件状态，以便重建状态。因此，注册官必须支持注册事件包。
Dialog package notifications are recommended by RFC 4235 to "only contain information on the dialogs whose state or participation information has changed." This specification extends RFC 4235 as follows. The Appearance Agent SHOULD send dialog event state notifications whenever the following events happen to UAs in the AOR group:
RFC 4235建议对话框包通知“仅包含状态或参与信息已更改的对话框的信息”。本规范扩展了RFC 4235，如下所示。每当AOR组中的UAs发生以下事件时，外观代理应发送对话框事件状态通知：
1. A call is received, placed, answered, or terminated.
1. 呼叫被接收、拨打、接听或终止。
2. A call is placed on or off hold.
2. 挂起或挂断通话。
3. A call is joined or replaced.
3. 呼叫被加入或替换。
4. An appearance number is reserved or released.
4. 保留或释放外观编号。
The Appearance Agent MUST allocate an appearance number for all incoming calls and send immediate notifications to the UAs subscribed to the shared group AOR. A new appearance number is allocated except for an incoming INVITE with a Join or Replaces header field. For this case, the appearance number should match the appearance number of the dialog being joined or replaced. If the INVITE Replaces or Join comes from outside the shared appearance group, the Appearance Agent will include a <joined-dialog> or <replaced-dialog> element in the NOTIFY containing the dialog information from the Replaces or Joined header field.
外观代理必须为所有传入呼叫分配外观号码，并立即向订阅共享组AOR的UAs发送通知。除了带有“加入”或“替换”标题字段的传入邀请之外，将分配新的外观编号。在这种情况下，外观编号应与正在连接或替换的对话框的外观编号相匹配。如果INVITE Replaces或Join来自共享外观组之外，则外观代理将在NOTIFY中包含<joined dialog>或<replaced dialog>元素，该元素包含Replaces或joined header字段中的对话框信息。
The Appearance Agent MUST be able to communicate with the forking proxy to learn about incoming calls and also to pass the appearance number to the proxy or ensure the Alert-Info header field is included in the INVITE with the appropriate appearance number.
外观代理必须能够与分叉代理进行通信，以了解来电情况，并将外观号码传递给代理，或确保邀请中包含具有适当外观号码的警报信息标题字段。
Note that UAs need to be able to handle incoming INVITEs without an appearance number assigned. This could be caused by a failure of the Appearance Agent or other error condition. Although the proper rendering of the INVITE may not be possible, this is better than ignoring or failing the INVITE.
请注意，UAs需要能够处理传入的邀请，而无需指定外观编号。这可能是由于外观代理失败或其他错误情况造成的。尽管可能无法正确呈现邀请，但这比忽略或失败邀请要好。
An Appearance Agent SHOULD assign an appearance number to an outgoing dialog if a PUBLISH has not been received selecting/seizing a particular appearance number.
如果尚未收到选择/捕获特定外观编号的发布，则外观代理应为传出对话框分配外观编号。
Note that if the shared appearance group has appearance-unaware UAs making calls, the Appearance Agent will still allocate appearance numbers for INVITEs sent by those UAs.
请注意，如果共享外观组中有外观不敏感的UAs进行呼叫，则外观代理仍将为这些UAs发送的邀请分配外观号码。
An Appearance Agent receiving a PUBLISH with an appearance number checks to make sure the publication is valid. An appearance number can be assigned to only one dialog unless there is a <joined-dialog>
接收具有外观编号的发布的外观代理将检查以确保该发布有效。除非存在<joined dialog>
or <replaced-dialog> element indicating that the dialog will be/has been replaced or joined. A 400 (Bad Request) response is returned if the chosen appearance number is invalid, and an immediate NOTIFY SHOULD be sent to the UA containing full dialog event state.
或<replaced dialog>元素，指示对话框将/已被替换或加入。如果选择的外观编号无效，则返回400（错误请求）响应，并应立即向UA发送包含完整对话事件状态的通知。
An Appearance Agent receiving a PUBLISH without an appearance number but with the 'shared' Event header field parameter present interprets this as a request by the UA to not assign an appearance number. If the Appearance Agent policy does not allow this, a 400 (Bad Request) response is returned. If policy does allow this, a 200 (OK) response is returned and no appearance number is allocated. An Appearance Agent does not have to share this dialog information (i.e., send a NOTIFY) with other UAs in the group as the information will not be rendered by the other UAs.
外观代理接收到发布时没有外观编号，但存在“共享”事件标头字段参数，将其解释为UA请求不分配外观编号。如果外观代理策略不允许这样做，则返回400（错误请求）响应。如果策略允许，则返回200（确定）响应，并且不分配外观编号。外观代理不必与组中的其他UAs共享此对话框信息（即发送通知），因为其他UAs不会提供该信息。
The Appearance Agent allocates an appearance number to a dialog from the time the appearance is requested via a PUBLISH or from the receipt of an INVITE to the time when the last dialog associated with the appearance is terminated, including all dialogs that are joined or replaced. During the early dialog state, the Appearance Agent controls the rate of dialog state publication using the Expires header field in 200 (OK) responses to PUBLISH requests. An interval of 3 minutes is RECOMMENDED. After the dialog associated with the publication has been confirmed, the expiration of the publication state has no effect on the appearance allocation. If the publication contains no dialog state information, the Appearance Agent MUST reserve the appearance number for the UA but cannot assign the appearance to any particular dialog of the UA. When the publication state is updated with any dialog information, the appearance number can then be assigned to the particular dialog. A UA that has been allocated an appearance number using a PUBLISH MAY free up the appearance number by removing the event state with a PUBLISH as described in [RFC3903].
从通过发布请求外观或从收到邀请到终止与外观关联的最后一个对话框（包括已加入或替换的所有对话框），外观代理会为对话框分配外观编号。在早期对话框状态期间，外观代理使用发布请求的200（确定）响应中的Expires标头字段控制对话框状态发布的速率。建议间隔3分钟。确认与发布关联的对话框后，发布状态的过期对外观分配没有影响。如果发布不包含对话框状态信息，则外观代理必须为UA保留外观编号，但不能将外观分配给UA的任何特定对话框。使用任何对话框信息更新发布状态时，可以将外观编号指定给特定对话框。已使用发布分配外观编号的UA可通过使用发布移除事件状态释放外观编号，如[RFC3903]中所述。
If an INVITE is sent by a member of the group to the shared AOR (i.e., they call their own AOR), the Appearance Agent MUST assign two appearance numbers. The first appearance number will be the one selected or assigned to the outgoing INVITE. The second appearance number will be another one assigned by the Appearance Agent for the INVITE as it is forked back to the members of the group.
如果组成员向共享AOR发送邀请（即，他们调用自己的AOR），则外观代理必须分配两个外观编号。第一个出场号码将是选择或分配给传出邀请的号码。第二个外观编号将是外观代理为邀请分配的另一个编号，因为它被分叉回组的成员。
The is to preserve a common behavior in legacy systems.
其目的是保留遗留系统中的常见行为。
If an INVITE is sent by a member of the group using the shared AOR or sent to the shared AOR and no appearance number is available, the proxy MAY reject the INVITE with a 403 (Forbidden) response code.
如果邀请由组成员使用共享AOR发送或发送到共享AOR，并且没有可用的出现号码，则代理可以使用403（禁止）响应代码拒绝邀请。
Appearance numbers are only used for dialogs in which one or more UAs associated with the group AOR are participants. If an incoming INVITE to the group AOR is forwarded to another AOR, the appearance number is immediately freed up and can be assigned to another dialog.
外观编号仅用于与组AOR关联的一个或多个UAs参与的对话框。如果组AOR的传入邀请被转发到另一个AOR，则外观编号将立即释放，并可以分配给另一个对话框。
The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive' elements are defined within a new XML namespace URI. This namespace is "urn:ietf:params:xml:ns:sa-dialog-info". The schema for these elements is:
“外观”、“连接的对话框”、“替换的对话框”和“独占”元素在新的XML命名空间URI中定义。这个名称空间是“urn:ietf:params:xml:ns:sa对话框信息”。这些元素的模式为：
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:sa-dialog-info"
xmlns="urn:ietf:params:xml:ns:sa-dialog-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:sa-dialog-info"
xmlns="urn:ietf:params:xml:ns:sa-dialog-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:element name="joined-dialog" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="call-id" type="xs:string"
use="mandatory"/>
<xs:attribute name="local-tag" type="xs:string"
use="mandatory"/>
<xs:attribute name="remote-tag" type="xs:string"
use="mandatory"/>
</xs:complexType>
</xs:element>
<xs:element name="joined-dialog" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="call-id" type="xs:string"
use="mandatory"/>
<xs:attribute name="local-tag" type="xs:string"
use="mandatory"/>
<xs:attribute name="remote-tag" type="xs:string"
use="mandatory"/>
</xs:complexType>
</xs:element>
<xs:element name="replaced-dialog" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="call-id" type="xs:string"
use="mandatory"/>
<xs:attribute name="local-tag" type="xs:string"
use="mandatory"/>
<xs:attribute name="remote-tag" type="xs:string"
use="mandatory"/>
</xs:complexType>
</xs:element>
<xs:element name="replaced-dialog" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="call-id" type="xs:string"
use="mandatory"/>
<xs:attribute name="local-tag" type="xs:string"
use="mandatory"/>
<xs:attribute name="remote-tag" type="xs:string"
use="mandatory"/>
</xs:complexType>
</xs:element>
<xs:element name="appearance" minOccurs="0" maxOccurs="1">
<xs:simpleType type="xs:integer">
</xs:simpleType>
</xs:element>
<xs:element name="appearance" minOccurs="0" maxOccurs="1">
<xs:simpleType type="xs:integer">
</xs:simpleType>
</xs:element>
<xs:element name="exclusive" minOccurs="0" maxOccurs="1">
<xs:simpleType type="xs:boolean">
</xs:simpleType>
</xs:element>
</xs:schema>
<xs:element name="exclusive" minOccurs="0" maxOccurs="1">
<xs:simpleType type="xs:boolean">
</xs:simpleType>
</xs:element>
</xs:schema>
This specification extends [RFC3261] to add an 'appearance' parameter to the Alert-Info header field and also to allow proxies to modify or delete the Alert-Info header field.
本规范扩展了[RFC3261]以向警报信息标题字段添加“外观”参数，并允许代理修改或删除警报信息标题字段。
The changes to the ABNF [RFC5234] in RFC 3261 are:
RFC 3261中ABNF[RFC5234]的更改如下：
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI
(generic-param / appearance-param) )
appearance-param = "appearance" EQUAL 1*DIGIT
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI
(generic-param / appearance-param) )
appearance-param = "appearance" EQUAL 1*DIGIT
A proxy inserting an 'appearance' Alert-Info parameter follows normal Alert-Info policies. To indicate the appearance number for this dialog, the proxy adds the Alert-Info header field with the 'appearance' parameter to the INVITE. If an Alert-Info is already present, the proxy adds the 'appearance' parameter to the Alert-Info header field. If an appearance number parameter is already present (associated with another AOR or by mistake), the value is rewritten adding the new appearance number. There MUST NOT be more than one appearance parameter in an Alert-Info header field.
插入“外观”警报信息参数的代理遵循正常警报信息策略。要指示此对话框的外观编号，代理会将带有“外观”参数的警报信息标题字段添加到邀请中。如果警报信息已存在，则代理会将“外观”参数添加到警报信息标题字段中。如果外观编号参数已存在（与另一个AOR关联或错误关联），则将重写该值并添加新的外观编号。警报信息标题字段中不得有多个外观参数。
If no special ringtone is desired, a normal ringtone SHOULD be indicated using the urn:alert:service:normal in the Alert-Info, as per [RFC7462]. The appearance number present in an Alert-Info header field SHOULD be rendered by the UA to the user, following the guidelines in Section 5.3. If the INVITE is forwarded to another AOR, the appearance parameter in the Alert-Info SHOULD be removed before forwarding outside the group.
如果不需要特殊铃声，则应根据[RFC7462]使用警报信息中的urn:alert:service:normal指示正常铃声。UA应根据第5.3节中的指南，向用户提供警报信息标题字段中的外观编号。如果邀请被转发到另一个AOR，则在转发到组外之前，应删除警报信息中的外观参数。
The determination as to what value to use in the appearance parameter can be done at the proxy that forks the incoming request to all the registered UAs.
关于在外观参数中使用什么值的确定可以在将传入请求分叉给所有注册UAs的代理上完成。
There is a variety of ways the proxy can determine what value it should use to populate this parameter. For example, the proxy could fetch this information by initiating a SUBSCRIBE request with Expires: 0 to the Appearance Agent for the AOR to fetch the list of lines that are in use. Alternatively, it could act like a UA that is a part of the shared appearance group and SUBSCRIBE to the State-Agent like any other UA. This would ensure that the active dialog information is available without having to poll on a need basis. It could keep track of the list of active calls for the appearance AOR based on how many unique INVITE requests it has forked to or received from the appearance AOR. Another approach would be for the Proxy to first send the incoming INVITE to the Appearance Agent, which would redirect to the shared appearance
代理可以通过多种方式确定应该使用什么值来填充此参数。例如，代理可以通过向AOR的外观代理发起一个Expires:0的订阅请求来获取此信息，以获取正在使用的行列表。或者，它可以像UA一样作为共享外观组的一部分，并像任何其他UA一样订阅状态代理。这将确保活动对话框信息可用，而无需根据需要进行轮询。它可以根据向外观AOR分叉或从外观AOR接收的唯一INVITE请求的数量，跟踪外观AOR的活动调用列表。另一种方法是代理首先将传入的INVITE发送给外观代理，后者将重定向到共享外观
group URI and escape the proper Alert-Info header field for the Proxy to recurse and distribute to the other UAs in the group.
组URI并转义适当的警报信息标头字段，以便代理递归并分发到组中的其他UAs。
The Appearance Agent needs to know about all incoming requests to the AOR in order to seize the appearance number. One way in which this could be done is for the Appearance Agent to register against the AOR with a higher q value. This will result in the INVITE being sent to the Appearance Agent first, then being offered to the UAs in the group.
外观代理需要知道所有传入到AOR的请求，以便获取外观编号。实现这一点的一种方法是外观代理以更高的q值注册AOR。这将导致邀请首先发送给外观代理，然后提供给组中的UAs。
The appearance number allocated to a call is an important concept that enables calls to be handled by multiple devices with heterogeneous user interfaces in a manner that still allows users to see a consistent model. Careful treatment of the appearance number is essential to meet the expectations of the users. Also, rendering the correct call/appearance state to users is also important.
分配给呼叫的外观号是一个重要的概念，它允许具有异构用户界面的多个设备以允许用户查看一致模型的方式处理呼叫。仔细处理外观编号对于满足用户的期望至关重要。此外，向用户呈现正确的调用/外观状态也很重要。
Since different UAs have different user interface capabilities, it is usual to find that some UAs have restrictions that others do not. Perfect interoperability across all UAs is clearly not possible, but by careful design, interoperability up to the limits of each UA can be achieved.
由于不同的UAs具有不同的用户界面功能，通常会发现一些UAs具有其他UAs没有的限制。在所有UA之间实现完美的互操作性显然是不可能的，但通过仔细设计，可以实现互操作性，达到每个UA的极限。
The following guidelines suggest how the appearance number should be handled in three typical user interface implementations.
以下指南建议在三种典型的用户界面实现中如何处理外观编号。
These devices are constrained by only having the capability of displaying status indications for a single appearance. The UA SHOULD still send messages annotated with appearance number "1". Any call indications for appearances other than for number "1" SHOULD be rejected with a 480 (Temporarily Unavailable) or 486 (Busy Here) response. Note that this means that a single appearance UA cannot answer its own call to the shared AOR, since this call would use a second appearance number.
这些设备仅具有显示单个外观状态指示的能力。UA仍应发送标有外观编号“1”的信息。除号码“1”外，任何出现的呼叫指示都应以480（暂时不可用）或486（此处忙）响应拒绝。请注意，这意味着单个外观UA无法应答自己对共享AOR的呼叫，因为此呼叫将使用第二个外观号码。
These devices are essentially single appearance phones that implement call waiting. They have a very simple user interface that allows them to switch between two appearances (toggle or flash hook) and perhaps audible tones to indicate the status of the other appearance. Only appearance numbers "1" and "2" will be used by these UAs.
这些设备基本上是实现呼叫等待的单外观手机。它们有一个非常简单的用户界面，允许它们在两种外观（切换或闪烁挂钩）之间切换，也可以通过声音指示另一种外观的状态。这些UAs仅使用外观编号“1”和“2”。
This UA is the typical 'business-class' hard-phone. A number of appearances are typically configured statically and labeled on buttons, and calls may be managed using these configured appearances. Any calls outside this range should be rejected, and not mapped to a free button. Users of these devices often seize specific appearance numbers for outgoing calls, and the UA will need to seize the appearance number and wait for confirmation from the Appearance Agent before proceeding with calls.
这款UA是典型的“商务舱”硬电话。许多外观通常是静态配置的，并标记在按钮上，调用可以使用这些配置的外观进行管理。任何超出此范围的呼叫都应被拒绝，并且不会映射到空闲按钮。这些设备的用户通常会为呼出的电话占用特定的外观号码，UA需要占用外观号码并等待外观代理的确认，然后才能继续通话。
This UA is typically a soft-phone or graphically rich user interface hard-phone. In these cases, even the idea of an appearance index may seem unnecessary. However, for these phones to be able to interwork successfully with other phone types, it is important that they still use the appearance index to govern the order of appearance of calls in progress. No specific guidance on presentation is given except that the order should be consistent. These devices can typically make calls without waiting for confirmation from the Appearance Agent on the appearance number.
该UA通常是软电话或图形丰富的用户界面硬电话。在这些情况下，即使是外观索引的想法似乎也没有必要。但是，为了使这些电话能够成功地与其他电话类型互通，重要的是它们仍然使用外观索引来管理正在进行的通话的外观顺序。除了顺序应一致外，没有给出关于演示的具体指导。这些设备通常可以在不等待外观代理确认外观号码的情况下拨打电话。
The problems faced by each style of user interface are readily seen in this example:
在本例中，可以很容易地看到每种类型的用户界面所面临的问题：
1. A call arrives at the shared appearance group and is assigned an appearance number of "1". All UAs should be able to render to the user the arrival of this call.
1. 呼叫到达共享外观组，并被分配外观号码“1”。所有UAs都应该能够向用户呈现此呼叫的到达。
2. Another call arrives at the shared appearance group and is assigned an appearance number of "2". The single appearance UA should not present this call to the user. Other UAs should have no problems presenting this call distinctly from the first call.
2. 另一个呼叫到达共享外观组，并被分配外观号码“2”。单一外观UA不应向用户显示此调用。其他UAs在显示此呼叫时应该不会有问题，因为它与第一次呼叫不同。
3. The first call clears, releasing appearance number "1". The single appearance UA should now be indicating no calls since it is unable to manage calls other than on the first appearance. Both shared appearance UAs should clearly show that appearance number "1" is now free, but that there is still a call on appearance number "2".
3. 第一次呼叫清除，释放外观号码“1”。单一外观UA现在应该指示没有呼叫，因为它无法管理除第一次外观之外的呼叫。两个共享外观UAs都应该清楚地显示外观编号“1”现在是免费的，但外观编号“2”仍然有通话。
4. A third call arrives and is assigned the appearance number of "1". All UAs should be able to render the arrival of this new call to the user. Multiple appearance UAs should continue to indicate the presence of the second call, and they should also
4. 第三个呼叫到达，并被分配出现号码“1”。所有UAs都应该能够向用户呈现此新呼叫的到达。多个UAs应继续指示存在第二个呼叫，并且它们也应
ensure that the presentation order is related to the appearance number and not the order of call arrival.
确保演示顺序与外观编号相关，而不是与呼叫到达顺序相关。
UAs that implement the shared appearances feature typically have a user interface that provides the state of other appearances in the group. As dialog state NOTIFYs from the Appearance Agent are processed, this information can be rendered. Even the simplest user interface typically has three states: idle, active, and hold. The idle state, usually indicated by lamp off, is indicated for an appearance when the appearance number is not associated with any dialogs, as reported by the Appearance Agent. The active state, usually indicated by a lamp on, means that an appearance number is associated with at least one dialog, as reported by the Appearance Agent. The hold state, often indicated by a blinking lamp, means the call state from the perspective of the UA in the shared appearance group is hold. This can be determined by the presence of the "+sip.rendering=no" feature tag [RFC3840] with the local target URI. Note that the hold state of the remote target URI is not relevant to this display. For joined dialogs, the state is rendered as hold only if all local target URIs are indicated with the "+sip.rendering=no" feature tag.
实现共享外观功能的UAs通常具有提供组中其他外观状态的用户界面。当处理来自外观代理的对话框状态通知时，可以呈现此信息。即使是最简单的用户界面通常也有三种状态：空闲、活动和保持。空闲状态通常由lamp off指示，当外观编号与任何对话框都不关联时，会为外观指示空闲状态，如外观代理报告的那样。激活状态通常由灯亮表示，表示外观编号与至少一个对话框关联，如外观代理报告的那样。保持状态通常由闪烁的指示灯指示，表示从共享外观组中UA的角度来看，呼叫状态为保持。这可以通过存在带有本地目标URI的“+sip.rendering=no”特征标记[RFC3840]来确定。请注意，远程目标URI的保持状态与此显示无关。对于连接的对话框，仅当所有本地目标URI都用“+sip.rendering=no”功能标记指示时，状态才会呈现为保持。
It is desirable to allow a basic UA that does not directly support shared appearance to be part of a shared appearance group. To support this, the Proxy must collaborate with the Appearance Agent. This is not required in the basic shared appearance architecture; consequently, shared appearance interoperability with non-shared appearance UAs will not be available in all shared appearance deployments.
希望允许不直接支持共享外观的基本UA成为共享外观组的一部分。为了支持这一点，代理必须与外观代理协作。这在基本共享外观体系结构中不是必需的；因此，与非共享外观UAs的共享外观互操作性在所有共享外观部署中都不可用。
First, a UA that does not support dialog events or the shared appearances feature will be discussed. Then, a UA that does support dialog events but not the shared appearances feature will be discussed.
首先，将讨论不支持对话事件或共享外观功能的UA。然后，将讨论支持对话事件但不支持共享外观功能的UA。
A UA that has no knowledge of appearances will only have appearance numbers for outgoing calls if assigned by the Appearance Agent. If the non-shared appearance UA does not support Join or Replaces, all dialogs SHOULD be marked "exclusive" to indicate that these options are not available. Marking these dialogs "exclusive" provides a better user experience and avoids extra SIP messaging failures.
不知道外观的UA只有在外观代理分配的情况下才有呼出电话的外观号码。如果非共享外观UA不支持联接或替换，则所有对话框都应标记为“独占”，以指示这些选项不可用。将这些对话框标记为“独占”可提供更好的用户体验，并避免额外的SIP消息传递失败。
In all cases, the Appearance Agent must be aware of the dialog lifetime to release appearances back into the group.
在所有情况下，外观代理都必须知道对话框的生存期，才能将外观释放回组中。
It is also desirable that any dialog state changes (such as hold, etc.) be made available to other UAs in the group through the Dialog Event Package. If the Appearance Agent includes a proxy that Record-Routes for dialogs from the non-shared-appearance-aware UA, the Appearance Agent will know about the state of dialogs including hold, etc. This information could be determined from inspection of non-end-to-end-encrypted INVITE and re-INVITE messages and added to the dialog information conveyed to other UAs.
还希望通过对话事件包将任何对话状态更改（如保持等）提供给组中的其他UAs。如果外观代理包括记录来自非共享外观感知UA的对话路由的代理，则外观代理将了解对话的状态，包括保持，等。可以通过检查非端到端加密的邀请和重新邀请消息来确定此信息，并将其添加到传递给其他UAs的对话框信息中。
Interoperability with UAs that support dialog events but not the shared appearances feature is more straightforward. As before, all appearance number assignments must be done by the Appearance Agent. The Appearance Agent SHOULD still include appearance information in NOTIFYs -- this UA will simply ignore this extra information. This type of UA will also ignore appearance number limitations and may attempt to join or replace dialogs marked exclusive. As a result, the Proxy or UAs need to reject such requests or the dialogs will be joined or taken.
与支持对话事件但不支持共享外观功能的UAs的互操作性更简单。与以前一样，所有外观编号分配都必须由外观代理完成。外观代理仍应在NOTIFY中包含外观信息——此UA将忽略此额外信息。这种类型的UA还将忽略外观编号限制，并可能尝试加入或替换标记为独占的对话框。因此，代理或UAs需要拒绝此类请求，否则将加入或执行对话框。
UAs can automatically discover if this feature is active for an AOR by looking for the 'shared' Event header field parameter in a response to a dialog package SUBSCRIBE to the AOR, so no provisioning for this is needed.
UAs可以通过在对订阅AOR的对话框包的响应中查找“共享”事件头字段参数，自动发现此功能对于AOR是否处于活动状态，因此无需为此进行设置。
The registrar will need to be provisioned to accept either first or third party registrations for the shared AOR. First party registration means the To and From URIs in the REGISTER request are the shared AOR URI. Third-party registration means the To URI is the shared AOR URI and the From URI is a different AOR, perhaps that of the individual user. Either the credentials of the shared AOR or the user MUST be accepted by the registrar and the Appearance Agent, depending on the authorization policy in place for the domain.
需要对注册机构进行设置，以接受共享AOR的第一方或第三方注册。第一方注册意味着注册请求中的往返URI是共享AOR URI。第三方注册意味着To URI是共享AOR URI，而From URI是不同的AOR，可能是单个用户的AOR。注册商和外观代理必须接受共享AOR或用户的凭据，具体取决于域的授权策略。
If the Appearance Agent needs to subscribe to the dialog state of the UAs, then the Appearance Agent and the UAs need to be provisioned with credentials so the UAs can authenticate the Appearance Agent.
如果外观代理需要订阅UAs的对话状态，则需要为外观代理和UAs提供凭据，以便UAs可以对外观代理进行身份验证。
In some cases, UAs in the shared appearance group might have a UI limitation on the number of appearances that can be rendered.
在某些情况下，共享外观组中的UAs可能对可以呈现的外观数量有UI限制。
Typically, this will be hard-phones with buttons/lamps instead of more flexible UIs. In this case, it can be useful for the Appearance Agent to know this maximum number. This can allow the Appearance Agent to apply policy when this limit is reached, e.g., deny a call. However, this mechanism does not provide any way to discover this by protocol means.
通常，这将是带有按钮/灯的硬手机，而不是更灵活的UI。在这种情况下，外观代理知道此最大数量可能会很有用。这允许外观代理在达到此限制时应用策略，例如拒绝呼叫。然而，该机制不提供任何通过协议手段发现该问题的方法。
The next section shows call flow and message examples. The flows and descriptions are non-normative. Note that, in these examples, all INVITEs sent by a UA in the group will be From the shared AOR (sip:HelpDesk@example.com in this case), and all INVITES sent to the group will have a Request-URI of the shared AOR. Any other requests would not apply to this feature and would be handled using normal SIP mechanisms.
下一节显示调用流和消息示例。流程和描述不规范。注意，在这些示例中，组中UA发送的所有邀请都将来自共享AOR（sip:HelpDesk@example.com在本例中），发送到组的所有邀请都将具有共享AOR的请求URI。任何其他请求都不适用于此功能，将使用正常的SIP机制进行处理。
Note that the first 12 examples assume the Appearance Agent is aware of dialog state events. The example in Section 11.13 shows the case where this is not the case, and, as a result, the Appearance Agent initiates a subscription to users of the shared AOR. Any of the other call flow examples could have shown this mode of operation as it is equally valid.
请注意，前12个示例假定外观代理知道对话框状态事件。第11.13节中的示例显示了并非如此的情况，因此，外观代理向共享AOR的用户发起订阅。任何其他调用流示例都可以显示这种操作模式，因为它同样有效。
Bob and Alice are in a shared appearance group identified by the shared appearance AOR sip:HelpDesk@example.com. Bob REGISTERs using contact sip:bob@ua2.example.com. Alice REGISTERs with contact sip:alice@ua1.example.com.
Bob和Alice位于共享外观AOR sip标识的共享外观组中：HelpDesk@example.com. Bob使用联系人sip注册：bob@ua2.example.com. Alice向联系人sip注册：alice@ua1.example.com.
UAs for Alice and Bob subscribe to the dialog package for the appearance AOR and publish dialog state to the Appearance Agent. Message exchanges between the Registrar, Appearance Agent, Alice, and Bob are shown below. The call flow examples below do not show the authentication of subscriptions, publications, and notifications. It should be noted that for security purposes, all publications and subscriptions must be authorized before they are accepted.
Alice和Bob的UAs订阅外观AOR的对话框包，并将对话框状态发布到外观代理。注册员、外观代理、Alice和Bob之间的消息交换如下所示。下面的调用流示例未显示订阅、发布和通知的身份验证。应该注意的是，出于安全目的，所有发布和订阅在被接受之前都必须经过授权。
Also note that registrations and subscriptions must all be refreshed by Alice at intervals determined by the expiration intervals returned by the Registrar or Appearance Agent.
还请注意，注册和订阅都必须由Alice按照注册商或外观代理返回的过期时间间隔来刷新。
Registrar Appearance Agent Alice Bob
| | | |
| | | |
|<--------------------------- REGISTER F1<| |
| | | |
Registrar Appearance Agent Alice Bob
| | | |
| | | |
|<--------------------------- REGISTER F1<| |
| | | |
|>F2 200 OK ----------------------------->| |
| | | |
| |<----- SUBSCRIBE F3<| |
| | | |
| |>F4 200 OK -------->| |
| | | |
| |>F5 NOTIFY -------->| |
| | | |
| |<-------- 200 OK F6<| |
| | | |
|<-------------------------------------------- REGISTER F7<|
| | | |
|>F8 200 OK ---------------------------------------------->|
| | | |
| |<---------------------- SUBSCRIBE F9<|
| | | |
| |>F10 200 OK ------------------------>|
| | | |
| |>F11 NOTIFY ------------------------>|
| | | |
| |<------------------------ 200 OK F12<|
| | | |
|>F2 200 OK ----------------------------->| |
| | | |
| |<----- SUBSCRIBE F3<| |
| | | |
| |>F4 200 OK -------->| |
| | | |
| |>F5 NOTIFY -------->| |
| | | |
| |<-------- 200 OK F6<| |
| | | |
|<-------------------------------------------- REGISTER F7<|
| | | |
|>F8 200 OK ---------------------------------------------->|
| | | |
| |<---------------------- SUBSCRIBE F9<|
| | | |
| |>F10 200 OK ------------------------>|
| | | |
| |>F11 NOTIFY ------------------------>|
| | | |
| |<------------------------ 200 OK F12<|
| | | |
Figure 1. Registration and Subscription Example
图1。注册和订阅示例
F1-F2: Alice registers AOR with
contact: <sip:alice@ua1.example.com>
F1-F2: Alice registers AOR with
contact: <sip:alice@ua1.example.com>
F1 Alice ----> Registrar
F1 Alice ----> Registrar
REGISTER sip:registrar.example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09
From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
To: <sip:HelpDesk@example.com>
CSeq: 2 REGISTER
Call-ID: d3281184-518783de-cc23d6bb
Contact: <sip:alice@ua1.example.com>
Max-Forwards: 70
Expires: 3600
Content-Length: 0
REGISTER sip:registrar.example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09
From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
To: <sip:HelpDesk@example.com>
CSeq: 2 REGISTER
Call-ID: d3281184-518783de-cc23d6bb
Contact: <sip:alice@ua1.example.com>
Max-Forwards: 70
Expires: 3600
Content-Length: 0
F2 Registrar ----> Alice
F2 Registrar ----> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09
CSeq: 2 REGISTER
Call-ID: d3281184-518783de-cc23d6bb
SIP/2.0 200 OK
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09
CSeq: 2 REGISTER
Call-ID: d3281184-518783de-cc23d6bb
From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
To: <sip:HelpDesk@example.com>;tag=1664573879820199
Contact: <sip:alice@ua1.example.com>;expires=3600
Content-Length: 0
From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
To: <sip:HelpDesk@example.com>;tag=1664573879820199
Contact: <sip:alice@ua1.example.com>;expires=3600
Content-Length: 0
F3 to F6: Alice also subscribes to the events associated with the Appearance AOR. Appearance Agent notifies Alice of the status.
F3到F6:Alice还订阅与外观AOR关联的事件。外观代理将状态通知Alice。
F3 Alice ----> Appearance Agent
F3 Alice ----> Appearance Agent
SUBSCRIBE sip:HelpDesk@example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
To: <sip:HelpDesk@example.com>
CSeq: 91 SUBSCRIBE
Call-ID: ef4704d9-bb68aa0b-474c9d94
Contact: <sip:alice@ua1.example.com>
Event: dialog;shared
Accept: application/dialog-info+xml
Max-Forwards: 70
Expires: 3700
Content-Length: 0
SUBSCRIBE sip:HelpDesk@example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
To: <sip:HelpDesk@example.com>
CSeq: 91 SUBSCRIBE
Call-ID: ef4704d9-bb68aa0b-474c9d94
Contact: <sip:alice@ua1.example.com>
Event: dialog;shared
Accept: application/dialog-info+xml
Max-Forwards: 70
Expires: 3700
Content-Length: 0
F4 Appearance Agent ----> Alice
F4 Appearance Agent ----> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
CSeq: 91 SUBSCRIBE
Call-ID: ef4704d9-bb68aa0b-474c9d94
From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
To: <sip:HelpDesk@example.com>;tag=1636248422222257
Allow-Events: dialog
Expires: 3700
Contact: <sip:appearanceagent.example.com>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
CSeq: 91 SUBSCRIBE
Call-ID: ef4704d9-bb68aa0b-474c9d94
From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
To: <sip:HelpDesk@example.com>;tag=1636248422222257
Allow-Events: dialog
Expires: 3700
Contact: <sip:appearanceagent.example.com>
Content-Length: 0
F5 Appearance Agent ----> Alice
F5 Appearance Agent ----> Alice
NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=1636248422222257
To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
Call-ID: ef4704d9-bb68aa0b-474c9d94
CSeq: 232 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846
Max-Forwards: 70
NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=1636248422222257
To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
Call-ID: ef4704d9-bb68aa0b-474c9d94
CSeq: 232 NOTIFY
Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846
Max-Forwards: 70
Content-Type: application/dialog-info+xml Event: dialog;shared Subscription-State: active;expires=3000 Contact: <sip:appearanceagent.example.com> Content-Length: ...
内容类型：应用程序/对话框信息+xml事件：对话框；共享订阅状态：活动；expires=3000联系人：<sip:appearanceagent.example.com>内容长度：。。。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="40"
state="full"
entity="sip:HelpDesk@example.com">
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="40"
state="full"
entity="sip:HelpDesk@example.com">
</dialog-info>
F6 Alice ----> Appearance Agent
F6 Alice ----> Appearance Agent
SIP/2.0 200 OK
Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846
From: <sip:HelpDesk@example.com>;tag=1636248422222257
To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
CSeq: 232 NOTIFY
Call-ID: ef4704d9-bb68aa0b-474c9d94
Contact: <sip:alice@ua1.example.com>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846
From: <sip:HelpDesk@example.com>;tag=1636248422222257
To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
CSeq: 232 NOTIFY
Call-ID: ef4704d9-bb68aa0b-474c9d94
Contact: <sip:alice@ua1.example.com>
Content-Length: 0
F7 Bob ----> Registrar
F7 Bob ----> Registrar
REGISTER sip:registrar.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B
From: <sip:bob@example.com>;tag=34831131
To: <sip:HelpDesk@example.com>
CSeq: 72 REGISTER
Call-ID: 139490230230249348
Contact: <sip:bob@ua2.example.com>
Max-Forwards: 70
Expires: 3600
Content-Length: 0
REGISTER sip:registrar.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B
From: <sip:bob@example.com>;tag=34831131
To: <sip:HelpDesk@example.com>
CSeq: 72 REGISTER
Call-ID: 139490230230249348
Contact: <sip:bob@ua2.example.com>
Max-Forwards: 70
Expires: 3600
Content-Length: 0
F8 Registrar ----> Bob
F8 Registrar ----> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B
From: <sip:bob@example.com>;tag=34831131
To: <sip:HelpDesk@example.com>;tag=fkwlwqi1
CSeq: 72 REGISTER
Call-ID: 139490230230249348
SIP/2.0 200 OK
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B
From: <sip:bob@example.com>;tag=34831131
To: <sip:HelpDesk@example.com>;tag=fkwlwqi1
CSeq: 72 REGISTER
Call-ID: 139490230230249348
Contact: <sip:alice@ua1.example.com>;expires=3200
Contact: <sip:bob@ua2.example.com>;expires=3600
Content-Length: 0
Contact: <sip:alice@ua1.example.com>;expires=3200
Contact: <sip:bob@ua2.example.com>;expires=3600
Content-Length: 0
In the call flow below, Bob and Alice are in a shared appearance group. Carol places a call to the shared appearance group AOR. The Appearance Agent sends NOTIFYs to Alice and Bob telling them what appearance the call is using. Both Alice and Bob's devices are alerted of the incoming call. Bob answers the call.
在下面的调用流中，Bob和Alice位于共享外观组中。Carol打电话给共享外观组AOR。外观代理向Alice和Bob发送NOTIFY，告诉他们呼叫使用的外观。Alice和Bob的设备都会收到来电警报。鲍勃接电话。
Note that it is possible that both Alice and Bob answer the call and send 200 (OK) responses to Carol. It is up to Carol to resolve this situation. Typically, Carol will send ACKs to both 200 OKs but send a BYE to terminate one of the dialogs. As a result, either Alice or Bob will receive the BYE and publish that their dialog is over. However, if Carol answers both Alice and Bob and keeps both dialogs active, then the Appearance Agent will need to resolve the situation by moving either Alice or Bob's dialog to a different appearance.
请注意，Alice和Bob都可能接听电话，并向Carol发送200（OK）个回复。该由卡罗尔来解决这个问题。通常，Carol将向两个200 OK发送确认，但发送BYE以终止其中一个对话框。因此，Alice或Bob将收到“再见”并发布他们的对话已结束。但是，如果Carol同时回答Alice和Bob并保持两个对话框都处于活动状态，则外观代理将需要通过将Alice或Bob的对话框移动到不同的外观来解决此问题。
All NOTIFY messages in the call flow below carry dialog events and only dialog states are mentioned for simplicity. For brevity, the details of some messages are not shown below. Note that the order of F2 - F5 and F7 - F8 could be reversed.
下面调用流中的所有NOTIFY消息都包含对话事件，为了简单起见，只提到对话状态。为简洁起见，下面未显示某些消息的详细信息。注意，F2-F5和F7-F8的顺序可以颠倒。
Forking Appearance
Carol Proxy Agent Alice Bob
| | | | |
|>F1 INVITE >| | | |
| |< - - - - - >| | |
| | |>F2 NOTIFY ----------->|
| | | | |
| | |<F3 200 OK -----------<|
| | | | |
| | |>F4 NOTIFY ->| |
| | | | |
| | |<-200 OK F5-<| |
|<- 100 F6 -<| | | |
| |>F7 INVITE (appearance=1) ---------->|
| | | | |
| |>F8 INVITE (appearance=1) >| |
| | | | |
| |<-------------------- Ringing 180 F9<|
|< 180 F10 -<| | | |
Forking Appearance
Carol Proxy Agent Alice Bob
| | | | |
|>F1 INVITE >| | | |
| |< - - - - - >| | |
| | |>F2 NOTIFY ----------->|
| | | | |
| | |<F3 200 OK -----------<|
| | | | |
| | |>F4 NOTIFY ->| |
| | | | |
| | |<-200 OK F5-<| |
|<- 100 F6 -<| | | |
| |>F7 INVITE (appearance=1) ---------->|
| | | | |
| |>F8 INVITE (appearance=1) >| |
| | | | |
| |<-------------------- Ringing 180 F9<|
|< 180 F10 -<| | | |
| |<--------- 180 Ringing F11<| |
|< 180 F12 -<| | | |
| | | | |
| |<------------------------ 200 OK F13<|
|< 200 F14 -<| | | |
| | | | |
| |>F15 CANCEL -------------->| |
| | | | |
| |<-------------- 200 OK F16<| |
| | | | |
| |<Request Cancelled 487 F17<| |
| | | | |
| |>F18 ACK ----------------->| |
|>F19 ACK -->| | | |
| |>F20 ACK --------------------------->|
| | | | |
|<=============Both way RTP established===========>|
| | | | |
| |< - - - - - >| | |
| | | | |
| | |>F21 NOTIFY >| |
| | | | |
| | |<- 200 F22 -<| |
| | | | |
| | |>F23 NOTIFY ---------->|
| | | | |
| | |<F24 200 OK ----------<|
| | | |
| |<--------- 180 Ringing F11<| |
|< 180 F12 -<| | | |
| | | | |
| |<------------------------ 200 OK F13<|
|< 200 F14 -<| | | |
| | | | |
| |>F15 CANCEL -------------->| |
| | | | |
| |<-------------- 200 OK F16<| |
| | | | |
| |<Request Cancelled 487 F17<| |
| | | | |
| |>F18 ACK ----------------->| |
|>F19 ACK -->| | | |
| |>F20 ACK --------------------------->|
| | | | |
|<=============Both way RTP established===========>|
| | | | |
| |< - - - - - >| | |
| | | | |
| | |>F21 NOTIFY >| |
| | | | |
| | |<- 200 F22 -<| |
| | | | |
| | |>F23 NOTIFY ---------->|
| | | | |
| | |<F24 200 OK ----------<|
| | | |
Figure 2. Appearance Selection for Incoming Call Example
图2。来电示例的外观选择
F4 Appearance Agent ----> Alice
F4 Appearance Agent ----> Alice
NOTIFY sip:alice@ua1.example.com SIP/2.0 From: <sip:HelpDesk@example.com>;tag=151702541050937 To: <sip:alice@example.com>;tag=18433323-C3D237CE Call-ID: 1e361d2f-a9f51109-bafe31d4 CSeq: 12 NOTIFY Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403 Max-Forwards: 70 Content-Type: application/dialog-info+xml Event: dialog;shared Subscription-State: active;expires=2800 Contact: <sip:appearanceagent.example.com> Content-Length: ...
通知sip：alice@ua1.example.comSIP/2.0发件人：<SIP:HelpDesk@example.com>;标签=151702541050937至：<sip:alice@example.com>;tag=18433323-C3D237CE呼叫ID:1e361d2f-a9f51109-bafe31d4 CSeq:12通过SIP/2.0/UDP appearanceagent.example.com通知；branch=z9hG4bK1403最大转发：70内容类型：应用程序/对话框信息+xml事件：对话框；共享订阅状态：活动；expires=2800联系人：<sip:appearanceagent.example.com>内容长度：。。。
<?xml version="1.0"?>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="13"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="2a7294823093f5274e3fd2ec54a2d76c"
call-id="14-1541707345"
remote-tag="44BAD75D-E3128D42"
direction="recipient">
<sa:appearance>1</sa:appearance>
<state>trying</state>
<remote>
<identity>sip:carol@ua.example.com</identity>
</remote>
</dialog>
</dialog-info>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="13"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="2a7294823093f5274e3fd2ec54a2d76c"
call-id="14-1541707345"
remote-tag="44BAD75D-E3128D42"
direction="recipient">
<sa:appearance>1</sa:appearance>
<state>trying</state>
<remote>
<identity>sip:carol@ua.example.com</identity>
</remote>
</dialog>
</dialog-info>
F7 Proxy ----> Bob
F7 Proxy ----> Bob
INVITE sip:bob@ua2.example.com SIP/2.0
Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji
From: <sip:carol@example.com>;tag=44BAD75D-E3128D42
To: <sip:HelpDesk@example.com>
CSeq: 106 INVITE
Call-ID: 14-1541707345
Contact: <sip:carol@ua3.example.com>
Max-Forwards: 69
Alert-Info: <urn:alert:service:normal>;appearance=1
Content-Type: application/sdp
Content-Length: ...
INVITE sip:bob@ua2.example.com SIP/2.0
Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji
From: <sip:carol@example.com>;tag=44BAD75D-E3128D42
To: <sip:HelpDesk@example.com>
CSeq: 106 INVITE
Call-ID: 14-1541707345
Contact: <sip:carol@ua3.example.com>
Max-Forwards: 69
Alert-Info: <urn:alert:service:normal>;appearance=1
Content-Type: application/sdp
Content-Length: ...
v=0
o=- 1102980499 1102980499 IN IP4 ua3.example.com
s=
c=IN IP4 ua3.example.com
t=0 0
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
v=0
o=- 1102980499 1102980499 IN IP4 ua3.example.com
s=
c=IN IP4 ua3.example.com
t=0 0
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F21 Appearance Agent ----> Alice
F21 Appearance Agent ----> Alice
NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=151702541050937
NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:HelpDesk@example.com>;tag=151702541050937
To: <sip:alice@example.com>;tag=18433323-C3D237CE Call-ID: 1e361d2f-a9f51109-bafe31d4 CSeq: 13 NOTIFY Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK4164F03j Max-Forwards: 70 Content-Type: application/dialog-info+xml Event: dialog;shared Subscription-State: active;expires=2500 Contact: <sip:appearanceagent.example.com> Content-Length: ...
致：<sip:alice@example.com>;tag=18433323-C3D237CE呼叫ID:1e361d2f-a9f51109-bafe31d4 CSeq:13通过SIP/2.0/UDP appearanceagent.example.com通知；branch=z9hG4bK4164F03j最大转发：70内容类型：应用程序/对话框信息+xml事件：对话框；共享订阅状态：活动；expires=2500联系人：<sip:appearanceagent.example.com>内容长度：。。。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="17"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="2a7294823093f5274e3fd2ec54a2d76c"
call-id="14-1541707345"
remote-tag="44BAD75D-E3128D42"
local-tag="7349dsfjkFD03s"
direction="recipient">
<sa:appearance>1</sa:appearance>
<state>confirmed</state>
<local>
<target>sip:bob@ua2.example.com</target>
</local>
<remote>
<identity>sip:carol@ua.example.com</identity>
</remote>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="17"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="2a7294823093f5274e3fd2ec54a2d76c"
call-id="14-1541707345"
remote-tag="44BAD75D-E3128D42"
local-tag="7349dsfjkFD03s"
direction="recipient">
<sa:appearance>1</sa:appearance>
<state>confirmed</state>
<local>
<target>sip:bob@ua2.example.com</target>
</local>
<remote>
<identity>sip:carol@ua.example.com</identity>
</remote>
</dialog>
</dialog-info>
In this scenario, Bob's UA places a call without first selecting/ seizing an appearance number. After Bob sends the INVITE, the appearance assigns an appearance number for it and notifies both Alice and Bob.
在这种情况下，Bob的UA在不首先选择/获取外观号码的情况下拨打电话。Bob发送邀请后，门面为其分配门面号码，并通知Alice和Bob。
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | | |
| |<------------------------------------- INVITE F1<|
| | | | |
| |>F2 100 Trying --------------------------------->|
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | | |
| |<------------------------------------- INVITE F1<|
| | | | |
| |>F2 100 Trying --------------------------------->|
|<-- INVITE F3<| | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<-- NOTIFY F4<| |
| | | | |
| | |>F5 200 OK -->| |
| | | |------- NOTIFY F6>|
| | | | |
| | | |<F7 200 OK ------<|
|>F8 180 ---->| | | |
| |>F9 180 Ringing -------------------------------->|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F10<| |
| | | | |
| | |>F11 200 OK ->| |
| | | |------ NOTIFY F12>|
| | | | |
| | | |<F13 200 OK -----<|
|>F14 200 OK ->| | | |
| |>F15 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F16<|
|<---- ACK F17<| | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F18<| |
| | | | |
| | |>F19 200 OK ->| |
| | | |------ NOTIFY F20>|
| | | | |
| | | |<F21 200 OK -----<|
| | | | |
|<-- INVITE F3<| | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<-- NOTIFY F4<| |
| | | | |
| | |>F5 200 OK -->| |
| | | |------- NOTIFY F6>|
| | | | |
| | | |<F7 200 OK ------<|
|>F8 180 ---->| | | |
| |>F9 180 Ringing -------------------------------->|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F10<| |
| | | | |
| | |>F11 200 OK ->| |
| | | |------ NOTIFY F12>|
| | | | |
| | | |<F13 200 OK -----<|
|>F14 200 OK ->| | | |
| |>F15 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F16<|
|<---- ACK F17<| | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F18<| |
| | | | |
| | |>F19 200 OK ->| |
| | | |------ NOTIFY F20>|
| | | | |
| | | |<F21 200 OK -----<|
| | | | |
Figure 3. Outgoing Call without Appearance Seizure Example
图3。无外观的传出呼叫示例
F1 Bob ----> Proxy
F1 Bob ----> Proxy
INVITE sip:carol@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF
From: <sip:HelpDesk@example.com>;tag=15A3DE7C-9283203B
To: <sip:carol@example.com>
CSeq: 1 INVITE
INVITE sip:carol@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF
From: <sip:HelpDesk@example.com>;tag=15A3DE7C-9283203B
To: <sip:carol@example.com>
CSeq: 1 INVITE
Call-ID: f3b3cbd0-a2c5775e-5df9f8d5
Contact: <sip:bob@ua2.example.com>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
Call-ID: f3b3cbd0-a2c5775e-5df9f8d5
Contact: <sip:bob@ua2.example.com>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980499 1102980499 IN IP4 ua2.example.com
s=IP SIP UA
c=IN IP4 ua2.example.com
t=0 0
a=sendrecv
m=audio 2236 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
v=0
o=- 1102980499 1102980499 IN IP4 ua2.example.com
s=IP SIP UA
c=IN IP4 ua2.example.com
t=0 0
a=sendrecv
m=audio 2236 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F4 Appearance Agent ----> Alice
F4 Appearance Agent ----> Alice
NOTIFY sip:alice@ua1.example.com SIP/2.0 Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK81d84f62 From: <sip:HelpDesk@example.com>;tag=1636248422222257 To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E Call-ID: ef4704d9-bb68aa0b-474c9d94 CSeq: 233 NOTIFY Max-Forwards: 70 Content-Type: application/dialog-info+xml Event: dialog;shared Subscription-State: active;expires=2200 Contact: <sip:appearanceagent.example.com> Content-Length: ...
通知sip：alice@ua1.example.comSIP/2.0 Via:SIP/2.0/UDP appearanceagent.example.com；分支=z9hG4bK81d84f62来自：HelpDesk@example.com>;标签=163624842257至：<sip:alice@example.com>;tag=925A3CAD-CEBB276E呼叫ID:ef4704d9-bb68aa0b-474c9d94 CSeq:233通知最大转发：70内容类型：应用程序/对话框信息+xml事件：对话框；共享订阅状态：活动；expires=2200联系人：<sip:appearanceagent.example.com>内容长度：。。。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="27"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="27"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
</local>
</dialog>
</dialog-info>
F6 Appearance Agent ----> Bob
F6 Appearance Agent ----> Bob
NOTIFY sip:bob@ua1.example.com SIP/2.0 From: <sip:HelpDesk@example.com>;tag=497585728578386 To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4 Call-ID: a7d559db-d6d7dcad-311c9e3a CSeq: 7 NOTIFY Via: SIP/2.0/UDP appearanceagent.example.com ;branch=z9hG4bK1711759878512309 Max-Forwards: 70 Content-Type: application/dialog-info+xml Event: dialog;shared Subscription-State: active;expires=2000 Contact: <sip:appearanceagent.example.com> Content-Length: ...
通知sip：bob@ua1.example.comSIP/2.0发件人：<SIP:HelpDesk@example.com>;标签=497585728578386至：<sip:bob@example.com>;tag=633618CF-B9C2EDA4呼叫ID:a7d559db-d6d7dcad-311c9e3a CSeq:7通知途径：SIP/2.0/UDP appearanceagent.example.com；branch=Z9HG4BK171759878512309最大转发：70内容类型：应用程序/对话框信息+xml事件：对话框；共享订阅状态：活动；expires=2000联系人：<sip:appearanceagent.example.com>内容长度：。。。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="78"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="02538339hfgdf3ce597f9e3egkl3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="78"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="02538339hfgdf3ce597f9e3egkl3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B" direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
In this scenario, Bob's UA sends out a dialog event PUBLISH with state (trying) selecting/seizing an appearance number before sending the INVITE. After receiving the 200 (OK) from the Appearance Agent confirming the appearance number, Bob's UA sends the INVITE to Carol and establishes a session. For brevity, details of some of the messages are not included in the message flows. Bob's UA puts as
在此场景中，Bob的UA发送一个对话框事件PUBLISH，状态为（正在尝试）在发送邀请之前选择/捕获一个外观编号。Bob的UA从门面代理处收到确认门面号码的200（确定）后，向Carol发送邀请并建立会话。为简洁起见，某些消息的详细信息不包括在消息流中。鲍伯的UA认为
much of the dialog information from F7 as can be determined in advance. In this case, the minimum of the Contact URI is included, which allows the Appearance Agent to correlate the INVITE with the PUBLISH.
F7中的大部分对话框信息可以提前确定。在本例中，包含了联系人URI的最小值，这允许外观代理将邀请与发布关联起来。
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | |
| | | |>F2 200 OK ------>|
| | | | |
| | |<-- NOTIFY F3<| |
| | | | |
| | |>F4 200 OK -->| |
| | | |------- NOTIFY F5>|
| | | | |
| | | |<F6 200 OK ------<|
| | | | |
| |<------------------------------------- INVITE F7<|
| | | | |
| |>F8 100 Trying --------------------------------->|
|<-- INVITE F9<| | | |
| | | |<---- PUBLISH F10<|
| | | | |
| | | |>F11 200 OK ----->|
| | | | |
|>F12 180 --->| | | |
| |>F13 180 Ringing ------------------------------->|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F14<| |
| | | | |
| | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>|
| | | | |
| | | |<F17 200 OK -----<|
|>F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F20<|
|<---- ACK F21<| | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F22<| |
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | |
| | | |>F2 200 OK ------>|
| | | | |
| | |<-- NOTIFY F3<| |
| | | | |
| | |>F4 200 OK -->| |
| | | |------- NOTIFY F5>|
| | | | |
| | | |<F6 200 OK ------<|
| | | | |
| |<------------------------------------- INVITE F7<|
| | | | |
| |>F8 100 Trying --------------------------------->|
|<-- INVITE F9<| | | |
| | | |<---- PUBLISH F10<|
| | | | |
| | | |>F11 200 OK ----->|
| | | | |
|>F12 180 --->| | | |
| |>F13 180 Ringing ------------------------------->|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F14<| |
| | | | |
| | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>|
| | | | |
| | | |<F17 200 OK -----<|
|>F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F20<|
|<---- ACK F21<| | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F22<| |
| | | | |
| | |>F23 200 OK ->| |
| | | |------ NOTIFY F24>|
| | | | |
| | | |<F25 200 OK -----<|
| | | | |
| | | | |
| | |>F23 200 OK ->| |
| | | |------ NOTIFY F24>|
| | | | |
| | | |<F25 200 OK -----<|
| | | | |
Figure 4. Outgoing Call with Appearance Seizure Example
图4。外拨电话，以外观为例
F1 to F4: Bob uses the shared appearance of the Help Desk on his UA to place an outgoing call (e.g., he goes off-hook). Before sending the outgoing INVITE request, Bob publishes to the Appearance Agent reserving appearance number 1. The Appearance Agent notifies Alice (and all other UAs, including Bob) of the event by sending NOTIFYs.
F1至F4：Bob使用其UA上服务台的共享外观拨打呼出电话（例如，他挂断电话）。在发送传出的INVITE请求之前，Bob将发布到保留外观编号1的外观代理。外观代理通过发送NOTIFY将事件通知Alice（以及所有其他UAs，包括Bob）。
F1 Bob ----> Appearance Agent
F1 Bob ----> Appearance Agent
PUBLISH sip:HelpDesk@example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 From: <sip:bob@example.com>;tag=44150CC6-A7B7919D To: <sip:HelpDesk@example.com> CSeq: 7 PUBLISH Call-ID: 44fwF144-F12893K38424 Contact: <sip:bob@ua2.example.com> Event: dialog;shared Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: ...
发布sip：HelpDesk@example.comSIP/2.0 Via:SIP/2.0/UDP ua2.example.com；分支=z9hG4bK61314d6446383E79来自：bob@example.com>;标签=44150CC6-A7B7919D至：<sip:HelpDesk@example.com>CSeq:7发布呼叫ID:44fwF144-F12893K38424联系人：<sip:bob@ua2.example.com>事件：对话框；共享最大转发：70内容类型：应用程序/对话框信息+xml内容长度：。。。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6"
state="full"
entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6"
state="full"
entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
F2 Appearance Agent ----> Bob
F2 Appearance Agent ----> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:HelpDesk@example.com>
CSeq: 7 PUBLISH
Call-ID: 44fwF144-F12893K38424
Contact: <sip:bob@ua2.example.com>
Event: dialog;shared
SIP-Etag: 482943245
Allow-Events: dialog
Expires: 60
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:HelpDesk@example.com>
CSeq: 7 PUBLISH
Call-ID: 44fwF144-F12893K38424
Contact: <sip:bob@ua2.example.com>
Event: dialog;shared
SIP-Etag: 482943245
Allow-Events: dialog
Expires: 60
Content-Length: 0
F7 Bob ---> Proxy
F7 Bob ---> Proxy
INVITE sip:carol@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK342122
Max-Forwards: 70
From: <sip:HelpDesk@example.com>;tag=15A3DE7C-9283203B
To: <sip:carol@example.com>
Call-ID: f3b3cbd0-a2c5775e-5df9f8d5
CSeq: 31 INVITE
Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp
Content-Length: ...
INVITE sip:carol@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK342122
Max-Forwards: 70
From: <sip:HelpDesk@example.com>;tag=15A3DE7C-9283203B
To: <sip:carol@example.com>
Call-ID: f3b3cbd0-a2c5775e-5df9f8d5
CSeq: 31 INVITE
Contact: <sip:bob@ua2.example.com>
Content-Type: application/sdp
Content-Length: ...
(SDP Not Shown)
（未显示SDP）
F10 Bob ----> Appearance Agent
F10 Bob ----> Appearance Agent
PUBLISH sip:HelpDesk@example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6d644638E7 From: <sip:bob@example.com>;tag=0CCf6-A7FdsB79D To: <sip:HelpDesk@example.com> CSeq: 437 PUBLISH Call-ID: fwF14d4-F1FFF2F2893K38424 Contact: <sip:bob@ua2.example.com> Event: dialog;shared Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: ...
发布sip：HelpDesk@example.comSIP/2.0 Via:SIP/2.0/UDP ua2.example.com；分支=z9hG4bK6d644638E7来自：bob@example.com>;标签=0CCf6-A7FdsB79D至：<sip:HelpDesk@example.com>CSeq:437发布呼叫ID:fwF14d4-F1FFF2893K38424联系人：<sip:bob@ua2.example.com>事件：对话框；共享最大转发：70内容类型：应用程序/对话框信息+xml内容长度：。。。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6"
state="full"
entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B"
direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
<remote>
<identity uri="sip:carol@example.com">
</identity>
</remote>
</dialog>
</dialog-info>
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6"
state="full"
entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B"
direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
<remote>
<identity uri="sip:carol@example.com">
</identity>
</remote>
</dialog>
</dialog-info>
In this scenario, Bob's UA sends out a dialog event PUBLISH with state (trying) indicating that he does not want to utilize an appearance number for this dialog. The PUBLISH does not have an appearance element but does have the 'shared' Event header field parameter. As a result, the Appearance Agent knows the UA does not wish to use an appearance number for this call. If the Appearance Agent does not wish to allow this, it would reject the PUBLISH with a 400 (Bad Request) response and the UA would know to re-PUBLISH selecting/seizing an appearance number.
在这个场景中，Bob的UA发送一个对话框事件PUBLISH，状态为（trying），表示他不想使用这个对话框的外观号。发布没有外观元素，但具有“共享”事件标题字段参数。因此，外观代理知道UA不希望为此呼叫使用外观号码。如果外观代理不允许这样做，它将以400（错误请求）响应拒绝发布，UA将知道重新发布选择/获取外观编号。
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | |
| | | |>F2 200 OK ------>|
| | | | |
| | |<-- NOTIFY F3<| |
| | | | |
| | |>F4 200 OK -->| |
| | | |------- NOTIFY F5>|
| | | | |
| | | |<F6 200 OK ------<|
| | | | |
| |<------------------------------------- INVITE F7<|
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | |
| | | |>F2 200 OK ------>|
| | | | |
| | |<-- NOTIFY F3<| |
| | | | |
| | |>F4 200 OK -->| |
| | | |------- NOTIFY F5>|
| | | | |
| | | |<F6 200 OK ------<|
| | | | |
| |<------------------------------------- INVITE F7<|
| | | | |
| |>F8 100 Trying --------------------------------->|
|<-- INVITE F9<| | | |
| | | |<---- PUBLISH F10<|
| | | | |
| | | |>F11 200 OK ----->|
| | | | |
|>F12 180 --->| | | |
| |>F13 180 Ringing ------------------------------->|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F14<| |
| | | | |
| | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>|
| | | | |
| | | |<F17 200 OK -----<|
|>F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F20<|
|<---- ACK F21<| | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F22<| |
| | | | |
| | |>F23 200 OK ->| |
| | | |------ NOTIFY F24>|
| | | | |
| | | |<F25 200 OK -----<|
| | | | |
| | | | |
| |>F8 100 Trying --------------------------------->|
|<-- INVITE F9<| | | |
| | | |<---- PUBLISH F10<|
| | | | |
| | | |>F11 200 OK ----->|
| | | | |
|>F12 180 --->| | | |
| |>F13 180 Ringing ------------------------------->|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F14<| |
| | | | |
| | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>|
| | | | |
| | | |<F17 200 OK -----<|
|>F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F20<|
|<---- ACK F21<| | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F22<| |
| | | | |
| | |>F23 200 OK ->| |
| | | |------ NOTIFY F24>|
| | | | |
| | | |<F25 200 OK -----<|
| | | | |
Figure 5. Outgoing Call without using an Appearance Number Example
图5。不使用外观号码的传出呼叫示例
F1 Bob ----> Appearance Agent
F1 Bob ----> Appearance Agent
PUBLISH sip:appearanceagent.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: <sip:bob@example.com>;tag=4415df82k39sf
To: <sip:HelpDesk@example.com>
CSeq: 7 PUBLISH
Call-ID: 44fwF144-F12893K38424
Contact: <sip:bob@ua2.example.com>
PUBLISH sip:appearanceagent.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: <sip:bob@example.com>;tag=4415df82k39sf
To: <sip:HelpDesk@example.com>
CSeq: 7 PUBLISH
Call-ID: 44fwF144-F12893K38424
Contact: <sip:bob@ua2.example.com>
Event: dialog;shared Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: ...
事件：对话框；共享最大转发：70内容类型：应用程序/对话框信息+xml内容长度：。。。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6"
state="full"
entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" direction="initiator">
<sa:exclusive>false</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="6"
state="full"
entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83" direction="initiator">
<sa:exclusive>false</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
Note that F7 would be the same as the previous example.
请注意，F7与前面的示例相同。
Bob and Carol are in a dialog, created, for example as in Section 11.3. Carol sends a BYE to Bob to terminate the dialog and the Appearance Agent de-allocates the appearance number used, sending notifications out to the UAs in the shared group.
Bob和Carol在一个对话框中，如第11.3节所述。Carol向Bob发送BYE以终止对话框，外观代理取消分配使用的外观编号，并向共享组中的UAs发送通知。
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
|>F22 BYE ---->| | | |
| |>F23 BYE --------------------------------------->|
| | | | |
| |<------------------------------------ 200 OK F24<|
|<--200 OK F25<| | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F26<| |
| | | | |
| | |>F27 200 OK ->| |
| | | |------ NOTIFY F28>|
| | | | |
| | | |<F29 200 OK -----<|
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
|>F22 BYE ---->| | | |
| |>F23 BYE --------------------------------------->|
| | | | |
| |<------------------------------------ 200 OK F24<|
|<--200 OK F25<| | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F26<| |
| | | | |
| | |>F27 200 OK ->| |
| | | |------ NOTIFY F28>|
| | | | |
| | | |<F29 200 OK -----<|
Figure 6. Appearance Release Example
图6。外观发布示例
F28 Appearance Agent ----> Bob
F28 Appearance Agent ----> Bob
NOTIFY sip:bob@ua1.example.com SIP/2.0 From: <sip:HelpDesk@example.com>;tag=497585728578386 To: <sip:bob@example.com> Call-ID: a7d559db-d6d7dcad-311c9e3a CSeq: 7 NOTIFY Via: SIP/2.0/UDP appearanceagent.example.com ;branch=z9hG4bK759878512309 Max-Forwards: 70 Content-Type: application/dialog-info+xml Event: dialog;shared Subscription-State: active;expires=1800 Contact: <sip:appearanceagent.example.com> Content-Length: ...
通知sip：bob@ua1.example.comSIP/2.0发件人：<SIP:HelpDesk@example.com>;标签=497585728578386至：<sip:bob@example.com>呼叫ID:a7d559db-d6d7dcad-311c9e3a CSeq:7 NOTIFY Via:SIP/2.0/UDP appearanceagent.example.com；branch=z9hG4bK759878512309最大转发：70内容类型：应用程序/对话框信息+xml事件：对话框；共享订阅状态：活动；expires=1800联系人：<sip:appearanceagent.example.com>内容长度：。。。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="27"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c"
direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>terminated</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="27"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c"
direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>terminated</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
</dialog>
</dialog-info>
In this scenario, Bob has an established dialog with Carol created using the call flows of Figures 1 or 2. Bob then places Carol on hold. Alice receives a notification of this and renders this on Alice's UI. Alice subsequently picks up the held call and has a established session with Carol. Finally, Carol hangs up. Alice must PUBLISH F32 to indicate that the INVITE F38 will be an attempt to
在这个场景中，Bob与Carol建立了一个对话，该对话是使用图1或图2的调用流创建的。然后鲍勃让卡罗尔等着。Alice收到此通知并在Alice的UI上呈现此信息。Alice随后接听了挂起的电话，并与Carol进行了一次既定的通话。最后，卡罗尔挂断了电话。Alice必须发布F32，以指示邀请F38将尝试
pickup the dialog between Carol and Bob and, hence, may use the same appearance number. This example also shows Secure SIP (sips) being used.
拾取Carol和Bob之间的对话，因此可以使用相同的外观编号。此示例还显示了正在使用的安全SIP（sips）。
Carol Proxy Alice Appearance Agent Bob
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| |<------------------------------(hold) INVITE F22<|
|<- INVITE F23<| | | |
| | | | |
|>F24 200 OK ->| | | |
| |>F25 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F26<|
|<---- ACK F27<| | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F28<| |
| | | | |
| | |>F29 200 OK ->| |
| | | |>F30 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F31<|
| | | | |
| | Alice decides to pick up the call |
| | | | |
| | |>F32 PUBLISH->| |
| | | | |
| | |<- 200 OK F33<| |
| | | | |
| | |<- NOTIFY F34<| |
| | | | |
| | |>F35 200 OK ->| |
| | | |>F36 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F37<|
| |<-- INVITE F38<| | |
|<- INVITE F39<|(w/ Replaces) | | |
|( w/ Replaces)| | | |
|>F40 200 OK ->| | | |
| |>F41 200 OK -->| | |
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | | |>F42 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F43<|
Carol Proxy Alice Appearance Agent Bob
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| |<------------------------------(hold) INVITE F22<|
|<- INVITE F23<| | | |
| | | | |
|>F24 200 OK ->| | | |
| |>F25 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F26<|
|<---- ACK F27<| | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F28<| |
| | | | |
| | |>F29 200 OK ->| |
| | | |>F30 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F31<|
| | | | |
| | Alice decides to pick up the call |
| | | | |
| | |>F32 PUBLISH->| |
| | | | |
| | |<- 200 OK F33<| |
| | | | |
| | |<- NOTIFY F34<| |
| | | | |
| | |>F35 200 OK ->| |
| | | |>F36 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F37<|
| |<-- INVITE F38<| | |
|<- INVITE F39<|(w/ Replaces) | | |
|( w/ Replaces)| | | |
|>F40 200 OK ->| | | |
| |>F41 200 OK -->| | |
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | | |>F42 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F43<|
| | |<- NOTIFY F44<| |
| | | | |
| | |>F45 200 OK ->| |
| | | | |
| |<----- ACK F46<| | |
|<---- ACK F47<| | | |
| | | | |
|<= Both way RTP established =>| | |
| | | | |
|>F48 BYE ---->| | | |
| |>F49 BYE --------------------------------------->|
| | | | |
| |<------------------------------------ OK 200 F50<|
|<- 200 OK F51<| | | |
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F52<| |
| | | | |
| | |>F53 200 OK ->| |
| | | | |
| | | |>F54 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F55<|
| | |<- NOTIFY F44<| |
| | | | |
| | |>F45 200 OK ->| |
| | | | |
| |<----- ACK F46<| | |
|<---- ACK F47<| | | |
| | | | |
|<= Both way RTP established =>| | |
| | | | |
|>F48 BYE ---->| | | |
| |>F49 BYE --------------------------------------->|
| | | | |
| |<------------------------------------ OK 200 F50<|
|<- 200 OK F51<| | | |
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F52<| |
| | | | |
| | |>F53 200 OK ->| |
| | | | |
| | | |>F54 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F55<|
Figure 7. Appearance Pickup Example
图7。外观拾取示例
F28 Appearance ----> Alice
F28 Appearance ----> Alice
NOTIFY sips:alice@ua1.example.com SIP/2.0 From: <sips:HelpDesk@example.com>;tag=151702541050937 To: <sips:alice@example.com>;tag=18433323-C3D237CE Call-ID: 1e361d2f-a9f51109-bafe31d4 CSeq: 12 NOTIFY Via: SIP/2.0/TLS appearanceagent.example.com ;branch=z9hG4bK1403 Max-Forwards: 70 Content-Type: application/dialog-info+xml Event: dialog;shared Subscription-State: active;expires=1800 Contact: <sips:appearanceagent.example.com> Content-Length: ...
通知sips：alice@ua1.example.comSIP/2.0发件人：<sips:HelpDesk@example.com>;标签=151702541050937至：<sips:alice@example.com>;tag=18433323-C3D237CE呼叫ID:1e361d2f-a9f51109-bafe31d4 CSeq:12通过SIP/2.0/TLS appearanceagent.example.com通知；branch=z9hG4bK1403最大转发：70内容类型：应用程序/对话框信息+xml事件：对话框；共享订阅状态：活动；expires=1800联系人：<sips:appearanceagent.example.com>内容长度：。。。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10"
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10"
state="partial"
entity="sips:HelpDesk@example.com">
<dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c"
direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>active</state>
<local>
<target uri="sips:bob@ua2.example.com">
<param pname="+sip.rendering" pval="no"/>
</target>
</local>
<remote>
<identity>sips:carol@example.com</identity>
<target uri="sips:carol@ua3.example.com" />
</remote>
</dialog>
</dialog-info>
state="partial"
entity="sips:HelpDesk@example.com">
<dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c"
direction="initiator">
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<state>active</state>
<local>
<target uri="sips:bob@ua2.example.com">
<param pname="+sip.rendering" pval="no"/>
</target>
</local>
<remote>
<identity>sips:carol@example.com</identity>
<target uri="sips:carol@ua3.example.com" />
</remote>
</dialog>
</dialog-info>
F32 Alice ----> Appearance Agent
F32 Alice ----> Appearance Agent
PUBLISH sips:HelpDesk@example.com SIP/2.0 Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A From: <sips:HelpDesk@example.com>;tag=44150CC6-A7B7919D To: <sips:alice@example.com>;tag=428765950880801 CSeq: 11 PUBLISH Call-ID: 87837Fkw87asfds Contact: <sips:alice@ua2.example.com> Event: dialog;shared Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: ...
发布SIP：HelpDesk@example.comSIP/2.0 Via:SIP/2.0/TLS ua2.example.com；分支=z9hG4bKa5d6cf61F5FBC05A来自：HelpDesk@example.com>;标签=44150CC6-A7B7919D至：<sips:alice@example.com>;tag=4287659508801 CSeq:11发布呼叫ID:87837Fkw87asfds联系人：<sips:alice@ua2.example.com>事件：对话框；共享最大转发：70内容类型：应用程序/对话框信息+xml内容长度：。。。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10"
state="full"
entity="sips:HelpDesk@example.com">
<dialog id="id3d4f9c83"
call-id="3d57cd17-47deb849-dca8b6c6"
local-tag="8C4183CB-BCEAB710" >
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10"
state="full"
entity="sips:HelpDesk@example.com">
<dialog id="id3d4f9c83"
call-id="3d57cd17-47deb849-dca8b6c6"
local-tag="8C4183CB-BCEAB710" >
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<sa:replaced-dialog
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
from-tag="15A3DE7C-9283203B"
to-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" />
<state>trying</state>
<local>
<target uri="sips:alice@ua1.example.com">
<param pname="+sip.rendering" pval="yes"/>
</target>
</local>
<remote>
<target uri="sips:carol@ua3.example.com" />
</remote>
</dialog>
</dialog-info>
<sa:replaced-dialog
call-id="f3b3cbd0-a2c5775e-5df9f8d5"
from-tag="15A3DE7C-9283203B"
to-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" />
<state>trying</state>
<local>
<target uri="sips:alice@ua1.example.com">
<param pname="+sip.rendering" pval="yes"/>
</target>
</local>
<remote>
<target uri="sips:carol@ua3.example.com" />
</remote>
</dialog>
</dialog-info>
F38 Alice ----> Proxy
F38 Alice ----> Proxy
INVITE sips:carol@example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK4ea695b5B376A60C
From: <sips:HelpDesk@example.com>;tag=8C4183CB-BCEAB710
To: <sips:carol@example.com:5075>
CSeq: 1 INVITE
Call-ID: 3d57cd17-47deb849-dca8b6c6
Contact: <sips:alice@ua1.example.com>
<all-one-line>
Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c
-1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B
</all-one-line>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
INVITE sips:carol@example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK4ea695b5B376A60C
From: <sips:HelpDesk@example.com>;tag=8C4183CB-BCEAB710
To: <sips:carol@example.com:5075>
CSeq: 1 INVITE
Call-ID: 3d57cd17-47deb849-dca8b6c6
Contact: <sips:alice@ua1.example.com>
<all-one-line>
Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c
-1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B
</all-one-line>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980497 1102980497 IN IP4 ua1.example.com
s=IP SIP UA
c=IN IP4 ua1.example.com
t=0 0
a=sendrecv
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
v=0
o=- 1102980497 1102980497 IN IP4 ua1.example.com
s=IP SIP UA
c=IN IP4 ua1.example.com
t=0 0
a=sendrecv
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
In this scenario, Bob calls Alice who is also in the shared appearance group. Only one appearance number is used for this dialog. This example also shows the use of the 'exclusive' tag to indicate that other UAs in the group can not join or take this dialog.
在此场景中，Bob调用Alice，Alice也在共享外观组中。此对话框仅使用一个外观编号。此示例还显示了使用“exclusive”标记表示组中的其他UAs不能加入或使用此对话框。
Carol Proxy Alice Appearance Agent Bob
| | | | |
| |<-------------------- INVITE (to Alice's UA) F1<|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | | | |
| | |<-- NOTIFY F2<| |
| | | | |
| | |>F3 200 OK -->| |
| | | |>F4 NOTIFY ------>|
| | | | |
| | | |<------ 200 OK F5<|
| |>F6 INVITE --->| | |
| | (appearance=1)| | |
| | | | |
| |<------ 180 F7<| | |
| | | | |
| |>F8 180 --------------------------------------->|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<-- NOTIFY F9<| |
| | | | |
| | |>F10 200 OK ->| |
| | | |>F11 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F12<|
| |<-- 200 OK F13<| | |
| | | | |
| |>F14 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F15<|
| | | | |
| |>F16 ACK ----->| | |
| | | | |
| | |<======= RTP established =======>|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
Carol Proxy Alice Appearance Agent Bob
| | | | |
| |<-------------------- INVITE (to Alice's UA) F1<|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | | | |
| | |<-- NOTIFY F2<| |
| | | | |
| | |>F3 200 OK -->| |
| | | |>F4 NOTIFY ------>|
| | | | |
| | | |<------ 200 OK F5<|
| |>F6 INVITE --->| | |
| | (appearance=1)| | |
| | | | |
| |<------ 180 F7<| | |
| | | | |
| |>F8 180 --------------------------------------->|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<-- NOTIFY F9<| |
| | | | |
| | |>F10 200 OK ->| |
| | | |>F11 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F12<|
| |<-- 200 OK F13<| | |
| | | | |
| |>F14 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F15<|
| | | | |
| |>F16 ACK ----->| | |
| | | | |
| | |<======= RTP established =======>|
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F17<| |
| | | | |
| | |>F18 200 OK ->| |
| | | |>F19 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F24<|
| | | | |
| | |<- NOTIFY F17<| |
| | | | |
| | |>F18 200 OK ->| |
| | | |>F19 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F24<|
| | | | |
Figure 8. Call between UAs within the Group Example
图8。组内UAs之间的调用示例
F19 Appearance Agent ----> Bob
F19 Appearance Agent ----> Bob
NOTIFY sip:bob@ua1.example.com SIP/2.0 From: <sip:HelpDesk@example.com>;tag=497585728578386 To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4 Call-ID: a7d559db-d6d7dcad-311c9e3a CSeq: 7 NOTIFY Via: SIP/2.0/UDP appearanceagent.example.com ;branch=z9hG4bK1711759878512309 Max-Forwards: 70 Content-Type: application/dialog-info+xml Event: dialog;shared Subscription-State: active;expires=1500 Contact: <sip:appearanceagent.example.com> Content-Length: ...
通知sip：bob@ua1.example.comSIP/2.0发件人：<SIP:HelpDesk@example.com>;标签=497585728578386至：<sip:bob@example.com>;tag=633618CF-B9C2EDA4呼叫ID:a7d559db-d6d7dcad-311c9e3a CSeq:7通知途径：SIP/2.0/UDP appearanceagent.example.com；branch=Z9HG4BK171759878512309最大转发：70内容类型：应用程序/对话框信息+xml事件：对话框；共享订阅状态：活动；expires=1500联系人：<sip:appearanceagent.example.com>内容长度：。。。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="3xdsd4f9c83"
call-id="b3cbd0-ad2c5775e-5df9f8d5"
local-tag="34322kdfr234f"
remote-tag="3153DE7C-928203B"
direction="initiator">
<sa:exclusive>true</sa:exclusive>
<sa:appearance>1</sa:appearance>
<state>confirmed</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
<remote>
<identity>sip:HelpDesk@example.com</identity>
<target uri="sip:alice@ua1.example.com" />
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10"
state="partial"
entity="sip:HelpDesk@example.com">
<dialog id="3xdsd4f9c83"
call-id="b3cbd0-ad2c5775e-5df9f8d5"
local-tag="34322kdfr234f"
remote-tag="3153DE7C-928203B"
direction="initiator">
<sa:exclusive>true</sa:exclusive>
<sa:appearance>1</sa:appearance>
<state>confirmed</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
<remote>
<identity>sip:HelpDesk@example.com</identity>
<target uri="sip:alice@ua1.example.com" />
</remote>
</dialog>
</remote>
</dialog>
<dialog id="4839589"
call-id="b3cbd0-ad2c5775e-5df9f8d5"
local-tag="3153DE7C-928203B"
remote-tag="34322kdfr234f"
direction="responder">
<sa:exclusive>true</sa:exclusive>
<sa:appearance>1</sa:appearance>
<state>confirmed</state>
<local>
<target uri="sip:alice@ua1.example.com" />
</local>
<remote>
<identity>sip:HelpDesk@example.com</identity>
<target uri="sip:bob@ua2.example.com" />
</remote>
</dialog>
<dialog id="4839589"
call-id="b3cbd0-ad2c5775e-5df9f8d5"
local-tag="3153DE7C-928203B"
remote-tag="34322kdfr234f"
direction="responder">
<sa:exclusive>true</sa:exclusive>
<sa:appearance>1</sa:appearance>
<state>confirmed</state>
<local>
<target uri="sip:alice@ua1.example.com" />
</local>
<remote>
<identity>sip:HelpDesk@example.com</identity>
<target uri="sip:bob@ua2.example.com" />
</remote>
</dialog>
</dialog-info>
</dialog-info>
In this scenario, Bob has a call with Carol. Bob makes a consultation call to Alice by putting Carol on hold and calling Alice. Bob's UA chooses not to have an appearance number for the call to Alice since it is treating it as part of the call to Carol. He indicates this in the PUBLISH F32, which contains the 'shared' Event header field parameter but no <appearance> element. The PUBLISH is sent before the INVITE to Alice to ensure no appearance number is assigned by the Appearance Agent. Finally, Bob hangs up with Alice and resumes the call with Carol. Dialog notifications of the consultation call are not shown, as they are not used.
在这种情况下，鲍勃与卡罗尔通了电话。鲍勃给爱丽丝打了一个咨询电话，让卡罗尔等一下，然后打电话给爱丽丝。Bob的UA选择不给Alice打电话，因为这是给Carol打电话的一部分。他在PUBLISH F32中指出了这一点，其中包含“shared”事件标题字段参数，但没有<appearance>元素。发布在邀请Alice之前发送，以确保外观代理未分配外观编号。最后，鲍勃挂断了爱丽丝的电话，继续与卡罗尔通话。咨询电话的对话框通知未显示，因为它们未被使用。
Note that if Carol hangs up while Bob is consulting with Alice, Bob can decide if he wants to reuse the appearance number used with Carol for the call with Alice. If not, Bob publishes the termination of the dialog with Carol and the Appearance Agent will re-allocate the appearance. If he wants to keep the appearance, Bob will publish the termination of the dialog with Carol and also publish the appearance with the dialog with Alice. This will result in Bob keeping the appearance number until he reports the dialog with Alice terminated.
请注意，如果Bob在咨询Alice时Carol挂断电话，Bob可以决定是否要在与Alice的通话中重复使用Carol使用的出场号码。如果没有，Bob将发布与Carol对话的终止，外观代理将重新分配外观。如果Bob想保留外观，他将与Carol一起发布对话的终止，并与Alice一起发布对话的外观。这将导致Bob保留外观编号，直到他报告与Alice的对话终止。
Note that the call flow would be similar if Bob called a music on hold server instead of Alice to implement a music on hold service as described in [RFC7088].
请注意，如果Bob调用music on hold服务器而不是Alice来实现[RFC7088]中所述的music on hold服务，则调用流程将类似。
Carol Proxy Alice Appearance Agent Bob
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| |<------------------------------(hold) INVITE F22<|
|<- INVITE F23<| | | |
| | | | |
|>F24 200 OK ->| | | |
| |>F25 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F26<|
|<---- ACK F27<| | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F28<| |
| | | | |
| | |>F29 200 OK ->| |
| | | |>F30 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F31<|
| | | | |
| | Bob makes a consultation call to Alice |
| | | | |
| | | |<---- PUBLISH F32<|
| | | | |
| | | |>F33 200 OK ----->|
| | | | |
| |<------------------------------------ INVITE F34<|
| | | | |
| |>F35 INVITE -->| | |
| | | | |
| |<-- 200 OK F36<| | |
| | | | |
| |>F37 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F38<|
| | | | |
| |>F39 ACK ----->| | |
| | | | |
| | |<======= RTP established =======>|
| | | | |
| | Bob hangs up with Alice |
| | | | |
| |<--------------------------------------- BYE F40<|
| | | | |
| |>F41 BYE ----->| | |
| | | | |
| |<-- 200 OK F42<| | |
Carol Proxy Alice Appearance Agent Bob
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| |<------------------------------(hold) INVITE F22<|
|<- INVITE F23<| | | |
| | | | |
|>F24 200 OK ->| | | |
| |>F25 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F26<|
|<---- ACK F27<| | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F28<| |
| | | | |
| | |>F29 200 OK ->| |
| | | |>F30 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F31<|
| | | | |
| | Bob makes a consultation call to Alice |
| | | | |
| | | |<---- PUBLISH F32<|
| | | | |
| | | |>F33 200 OK ----->|
| | | | |
| |<------------------------------------ INVITE F34<|
| | | | |
| |>F35 INVITE -->| | |
| | | | |
| |<-- 200 OK F36<| | |
| | | | |
| |>F37 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F38<|
| | | | |
| |>F39 ACK ----->| | |
| | | | |
| | |<======= RTP established =======>|
| | | | |
| | Bob hangs up with Alice |
| | | | |
| |<--------------------------------------- BYE F40<|
| | | | |
| |>F41 BYE ----->| | |
| | | | |
| |<-- 200 OK F42<| | |
| | | | |
| |>F43 200 OK ------------------------------------>|
| | | | |
| |<----------------------------(unhold) INVITE F44<|
|<- INVITE F45<| | | |
| | | | |
|>F46 200 OK ->| | | |
| |>F47 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F48<|
|<---- ACK F49<| | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F50<| |
| | | | |
| | |>F51 200 OK ->| |
| | | |>F52 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F53<|
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| | | | |
| |>F43 200 OK ------------------------------------>|
| | | | |
| |<----------------------------(unhold) INVITE F44<|
|<- INVITE F45<| | | |
| | | | |
|>F46 200 OK ->| | | |
| |>F47 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F48<|
|<---- ACK F49<| | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F50<| |
| | | | |
| | |>F51 200 OK ->| |
| | | |>F52 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F53<|
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
Figure 9. Consultation Hold with Appearances Example
图9。咨询会举行，以身作则
F32 Bob ----> Appearance Agent
F32 Bob ----> Appearance Agent
PUBLISH sip:HelpDesk@example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A From: <sip:bob@example.com>;tag=44150CC6-A7B7919D To: <sip:HelpDesk@example.com>;tag=428765950880801 CSeq: 11 PUBLISH Call-ID: 44fwF144-F12893K38424 Contact: <sip:bob@ua2.example.com> Event: dialog;shared Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: ...
发布sip：HelpDesk@example.comSIP/2.0 Via:SIP/2.0/UDP ua2.example.com；分支=z9hG4bKa5d6cf61F5FBC05A来自：bob@example.com>;标签=44150CC6-A7B7919D至：<sip:HelpDesk@example.com>;tag=4287659508801 CSeq:11发布呼叫ID:44fwF144-F12893K38424联系人：<sip:bob@ua2.example.com>事件：对话框；共享最大转发：70内容类型：应用程序/对话框信息+xml内容长度：。。。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10"
state="full"
entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83"
call-id="b3cbd0-ad2c5775e-5df9f8d5"
local-tag="3153DE7C-928203B"
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10"
state="full"
entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83"
call-id="b3cbd0-ad2c5775e-5df9f8d5"
local-tag="3153DE7C-928203B"
direction="initiator">
<sa:exclusive>true</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
<remote>
<identity>sip:HelpDesk@example.com</identity>
<target uri="sip:alice@ua1.example.com" />
</remote>
</dialog>
</dialog-info>
direction="initiator">
<sa:exclusive>true</sa:exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@ua2.example.com">
</target>
</local>
<remote>
<identity>sip:HelpDesk@example.com</identity>
<target uri="sip:alice@ua1.example.com" />
</remote>
</dialog>
</dialog-info>
In this call flow, a call answered by Bob is joined by Alice or "bridged". The Join header field is used by Alice to request this bridging. If Bob did not support media mixing, Bob could obtain conferencing resources as described in [RFC4579].
在此呼叫流中，由Bob应答的呼叫由Alice或“bridged”加入。Alice使用Join header字段请求此桥接。如果Bob不支持媒体混合，Bob可以获得[RFC4579]中所述的会议资源。
Carol Forking Proxy Appearance Agent Alice Bob
| | | | |
|<=============Both way RTP established===========>|
| | | | |
| | |< PUBLISH F22| |
| | | | |
| | |>F23 200 OK >| |
| | | | |
| |<---- INVITE (w/ Join) F24<| |
| | | | |
| |>F25 INVITE (w/Join)---------------->|
| | | | |
| |<---- OK 200 Contact:Bob;isfocus F26<|
| | | | |
| |< - - - - - >| | |
| | | | |
| | |>F27 NOTIFY >| |
| | | | |
| | |< 200 OK F28<| |
| | | | |
| | |>F29 NOTIFY ---------->|
| | | | |
| | |<F30 200 OK ----------<|
| | | | |
| |>F31 200 OK Contact:B----->| |
| | | | |
| |<----------------- ACK F32<| |
Carol Forking Proxy Appearance Agent Alice Bob
| | | | |
|<=============Both way RTP established===========>|
| | | | |
| | |< PUBLISH F22| |
| | | | |
| | |>F23 200 OK >| |
| | | | |
| |<---- INVITE (w/ Join) F24<| |
| | | | |
| |>F25 INVITE (w/Join)---------------->|
| | | | |
| |<---- OK 200 Contact:Bob;isfocus F26<|
| | | | |
| |< - - - - - >| | |
| | | | |
| | |>F27 NOTIFY >| |
| | | | |
| | |< 200 OK F28<| |
| | | | |
| | |>F29 NOTIFY ---------->|
| | | | |
| | |<F30 200 OK ----------<|
| | | | |
| |>F31 200 OK Contact:B----->| |
| | | | |
| |<----------------- ACK F32<| |
| | | | |
| |>ACK F33---------------------------->|
| | | | |
| |<-----INVITE Contact:Bob;isfocus F34<|
|<-INVITE F35| | | |
| | | | |
|>F26 200 -->| | | |
| |>F37 200 OK ------------------------>|
| | | | |
| |<--------------------------- ACK F38<|
|<--- ACK F39| | | |
| | | |<==RTP==>|
|<=============Both way RTP established===========>|
| | | | |
| |< - - - - - >| | |
| | | | |
| | |>F40 NOTIFY >| |
| | | | |
| | |< 200 OK F41<| |
| | | | |
| | |>F42 NOTIFY ---------->|
| | | | |
| | |<F43 200 OK ----------<|
| | | | |
| | | | |
| |>ACK F33---------------------------->|
| | | | |
| |<-----INVITE Contact:Bob;isfocus F34<|
|<-INVITE F35| | | |
| | | | |
|>F26 200 -->| | | |
| |>F37 200 OK ------------------------>|
| | | | |
| |<--------------------------- ACK F38<|
|<--- ACK F39| | | |
| | | |<==RTP==>|
|<=============Both way RTP established===========>|
| | | | |
| |< - - - - - >| | |
| | | | |
| | |>F40 NOTIFY >| |
| | | | |
| | |< 200 OK F41<| |
| | | | |
| | |>F42 NOTIFY ---------->|
| | | | |
| | |<F43 200 OK ----------<|
| | | | |
Figure 10. Joining or Bridging an Appearance Example
图10。连接或桥接外观示例
F22 Alice ----> Appearance Agent
F22 Alice ----> Appearance Agent
PUBLISH sip:HelpDesk@example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A From: <sip:alice@example.com>;tag=44150CC6-A7B7919D To: <sip:HelpDesk@example.com>;tag=428765950880801 CSeq: 11 PUBLISH Call-ID: 87837Fkw87asfds Contact: <sip:alice@ua2.example.com> Event: dialog;shared Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: ...
发布sip：HelpDesk@example.comSIP/2.0 Via:SIP/2.0/UDP ua2.example.com；分支=z9hG4bKa5d6cf61F5FBC05A来自：alice@example.com>;标签=44150CC6-A7B7919D至：<sip:HelpDesk@example.com>;tag=4287659508801 CSeq:11发布呼叫ID:87837Fkw87asfds联系人：<sip:alice@ua2.example.com>事件：对话框；共享最大转发：70内容类型：应用程序/对话框信息+xml内容长度：。。。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10"
state="full"
entity="sip:HelpDesk@example.com:5060">
<dialog id="id3d4f9c83"
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10"
state="full"
entity="sip:HelpDesk@example.com:5060">
<dialog id="id3d4f9c83"
call-id="dc95da63-60db1abd-d5a74b48"
local-tag="605AD957-1F6305C2" >
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<sa:joined-dialog
call-id="14-1541707345"
from-tag="44BAD75D-E3128D42"
to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" />
<state>trying</state>
<local>
<target uri="sip:alice@ua1.example.com">
</target>
</local>
<remote>
<target uri="sip:bob@example.com" />
</remote>
</dialog>
</dialog-info>
call-id="dc95da63-60db1abd-d5a74b48"
local-tag="605AD957-1F6305C2" >
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<sa:joined-dialog
call-id="14-1541707345"
from-tag="44BAD75D-E3128D42"
to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" />
<state>trying</state>
<local>
<target uri="sip:alice@ua1.example.com">
</target>
</local>
<remote>
<target uri="sip:bob@example.com" />
</remote>
</dialog>
</dialog-info>
F24 Alice ----> Proxy
F24 Alice ----> Proxy
INVITE sip:bob@ua.example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31
From: <sip:HelpDesk@example.com>;tag=605AD957-1F6305C2
To: <sip:bob@ua.example.com>
CSeq: 2 INVITE
Call-ID: dc95da63-60db1abd-d5a74b48
Contact: <sip:alice@ua1.example.com>
<all-one-line>
Join: 14-1541707345;to-tag=d3b06488-1dd1-11b2-88c5
-b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42
</all-one-line>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
INVITE sip:bob@ua.example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31
From: <sip:HelpDesk@example.com>;tag=605AD957-1F6305C2
To: <sip:bob@ua.example.com>
CSeq: 2 INVITE
Call-ID: dc95da63-60db1abd-d5a74b48
Contact: <sip:alice@ua1.example.com>
<all-one-line>
Join: 14-1541707345;to-tag=d3b06488-1dd1-11b2-88c5
-b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42
</all-one-line>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1103061265 1103061265 IN IP4 ua1.example.com
s=IP SIP UA
c=IN IP4 ua1.example.com
t=0 0
a=sendrecv
m=audio 2236 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
v=0
o=- 1103061265 1103061265 IN IP4 ua1.example.com
s=IP SIP UA
c=IN IP4 ua1.example.com
t=0 0
a=sendrecv
m=audio 2236 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol, then becomes unreachable. When he fails to refresh his publication to the appearance agent, the Appearance Agent declares the dialog terminated and frees up the appearance using NOTIFYs F14 and F16. After retransmitting the NOTIFY to Bob (in not shown messages F17, F18, etc.), the subscription is terminated.
鲍勃保留了一次公开露面的机会，给卡罗尔发了一封邀请信，然后就无法联系到他了。当他未能将其发布刷新到外观代理时，外观代理将声明对话框终止，并使用NOTIFY F14和F16释放外观。将通知重新传输给Bob后（在未显示的消息F17、F18等中），订阅终止。
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | |
| | | |>F2 200 OK ------>|
| | | | |
| | |<-- NOTIFY F3<| |
| | | | |
| | |>F4 200 OK -->| |
| | | |------- NOTIFY F5>|
| | | | |
| | | |<F6 200 OK ------<|
| | | | |
| |<------------------------------------- INVITE F7<|
| | | | |
| |>F8 100 Trying --------------------------------->|
|<-- INVITE F9<| | | |
| | | |<---- PUBLISH F10<|
| | | | |
| | | |>F11 200 OK ----->|
| | | | |
|>F12 180 --->| | | |
| |>F13 180 Ringing ------------------------------->|
| | | | |
| | | | Bob goes offline |
| | | | |
| | | Appearance selection times out |
| | | | |
| | |<- NOTIFY F14<| |
| | | | |
| | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>|
| | | | |
| | | NOTIFY is retransmitted |
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | |
| | | |>F2 200 OK ------>|
| | | | |
| | |<-- NOTIFY F3<| |
| | | | |
| | |>F4 200 OK -->| |
| | | |------- NOTIFY F5>|
| | | | |
| | | |<F6 200 OK ------<|
| | | | |
| |<------------------------------------- INVITE F7<|
| | | | |
| |>F8 100 Trying --------------------------------->|
|<-- INVITE F9<| | | |
| | | |<---- PUBLISH F10<|
| | | | |
| | | |>F11 200 OK ----->|
| | | | |
|>F12 180 --->| | | |
| |>F13 180 Ringing ------------------------------->|
| | | | |
| | | | Bob goes offline |
| | | | |
| | | Appearance selection times out |
| | | | |
| | |<- NOTIFY F14<| |
| | | | |
| | |>F15 200 OK ->| |
| | | |------ NOTIFY F16>|
| | | | |
| | | NOTIFY is retransmitted |
Figure 11. Loss of Appearance during Allocation Example
图11。在分配示例中丢失外观
Bob and Alice both try to reserve appearance 2 by publishing at the same time. The Appearance Agent allocates the appearance to Bob by sending a 200 OK and denies it to Alice by sending a 400 (Bad Request) response. After the NOTIFY F5, Alice learns that Bob is using appearance 2. Alice then attempts to reserve appearance 3 by publishing, which is then accepted.
Bob和Alice都试图通过同时发布来保留外观2。外观代理通过发送200 OK将外观分配给Bob，并通过发送400（错误请求）响应将外观拒绝给Alice。在通知F5之后，Alice知道Bob正在使用外观2。Alice然后试图通过发布来保留外观3，然后被接受。
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | (appearance=2)
| | |>F2 PUBLISH ->| |
| | | (appearance=2) |
| | | | |
| | | |>F3 200 OK ------>|
| | |<---- F4 400 <| |
| | | | |
| | |<-- NOTIFY F5<| |
| | | | |
| | |>F6 200 OK -->| |
| | | |------- NOTIFY F7>|
| | | | |
| | | |<F8 200 OK ------<|
| | | | |
| |<------------------------------------- INVITE F9<|
| | | | |
| |>F10 100 Trying -------------------------------->|
|<- INVITE F11<| | | |
| | | |<---- PUBLISH F12<|
| | | | (appearance=2)
| | | |>F13 200 OK ----->|
| | |>F14 PUBLISH->| |
| | | (appearance=3) |
| | | | |
| | |<--- F15 200 <| |
| | | | |
| | |<- NOTIFY F16<| |
| | | | |
| | |>F17 200 OK ->| |
Dave | | |------ NOTIFY F18>|
| | | | |
| | | |<F19 200 OK -----<|
| |<-- INVITE F20<| | |
| | | | |
| |>F21 100 ----->| | |
|<- INVITE F22<| | | |
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<----- PUBLISH F1<|
| | | | (appearance=2)
| | |>F2 PUBLISH ->| |
| | | (appearance=2) |
| | | | |
| | | |>F3 200 OK ------>|
| | |<---- F4 400 <| |
| | | | |
| | |<-- NOTIFY F5<| |
| | | | |
| | |>F6 200 OK -->| |
| | | |------- NOTIFY F7>|
| | | | |
| | | |<F8 200 OK ------<|
| | | | |
| |<------------------------------------- INVITE F9<|
| | | | |
| |>F10 100 Trying -------------------------------->|
|<- INVITE F11<| | | |
| | | |<---- PUBLISH F12<|
| | | | (appearance=2)
| | | |>F13 200 OK ----->|
| | |>F14 PUBLISH->| |
| | | (appearance=3) |
| | | | |
| | |<--- F15 200 <| |
| | | | |
| | |<- NOTIFY F16<| |
| | | | |
| | |>F17 200 OK ->| |
Dave | | |------ NOTIFY F18>|
| | | | |
| | | |<F19 200 OK -----<|
| |<-- INVITE F20<| | |
| | | | |
| |>F21 100 ----->| | |
|<- INVITE F22<| | | |
Figure 12. Appearance Seizure Contention Race Condition Example
图12。竞争条件示例
In this scenario, the Appearance Agent does not have any way of knowing Bob's dialog state information, except through Bob. This could be because the Appearance Agent is not part of a B2BUA, or
在这个场景中，外观代理没有任何方式知道Bob的对话框状态信息，除非通过Bob。这可能是因为外观代理不是B2BUA的一部分，或者
perhaps Bob is remotely registering. When Bob registers, the Appearance Agent receives a registration event package notification from the registrar. The Appearance Agent then SUBSCRIBEs to Bob's dialog event state using Event:dialog in the SUBSCRIBE. Whenever Bob's dialog state changes, Bob's UA sends a NOTIFY to the Appearance Agent which then notifies the other UAs in the group.
也许鲍勃正在远程注册。当Bob注册时，外观代理从注册器接收注册事件包通知。然后，外观代理使用SUBSCRIBE中的event:dialog订阅Bob的对话框事件状态。每当Bob的对话状态改变时，Bob的UA都会向外观代理发送通知，然后外观代理会通知组中的其他UA。
Carol Proxy Alice Appearance Agent Bob
| | | | |
| |<----------------------------------- REGISTER F1<|
| | | | |
| |>F2 200 OK ------------------------------------->|
| | | | |
| |>F3 NOTIFY ------------------>| |
| | | | |
| |<------------------ 200 OK F4<| |
| | | |---- SUBSCRIBE F5>|
| | | | |
| | | |<F6 200 OK ------<|
| | | | |
| | | |<------ NOTIFY F7<|
| | | | |
| | | |>F8 200 OK ------>|
| | | | |
| | | |<--- SUBSCRIBE F9<|
| | | | |
| | | |>F10 200 OK ----->|
| | | | |
| | | |------ NOTIFY F11>|
| | | | |
| | | |<F12 200 OK -----<|
| | | | |
| |<------------------------------------ INVITE F13<|
| | | | |
| |>F14 100 Trying -------------------------------->|
|<- INVITE F15<| | | |
| | | |<----- NOTIFY F16<|
| | | | |
| | | |>F17 200 OK ----->|
| | |<- NOTIFY F18<| |
| | | | |
| | |>F19 200 OK ->| |
| | | |------ NOTIFY F20>|
| | | | |
| | | |<F21 200 OK -----<|
|>F22 180 --->| | | |
| |>F23 180 Ringing ------------------------------->|
| | | | |
Carol Proxy Alice Appearance Agent Bob
| | | | |
| |<----------------------------------- REGISTER F1<|
| | | | |
| |>F2 200 OK ------------------------------------->|
| | | | |
| |>F3 NOTIFY ------------------>| |
| | | | |
| |<------------------ 200 OK F4<| |
| | | |---- SUBSCRIBE F5>|
| | | | |
| | | |<F6 200 OK ------<|
| | | | |
| | | |<------ NOTIFY F7<|
| | | | |
| | | |>F8 200 OK ------>|
| | | | |
| | | |<--- SUBSCRIBE F9<|
| | | | |
| | | |>F10 200 OK ----->|
| | | | |
| | | |------ NOTIFY F11>|
| | | | |
| | | |<F12 200 OK -----<|
| | | | |
| |<------------------------------------ INVITE F13<|
| | | | |
| |>F14 100 Trying -------------------------------->|
|<- INVITE F15<| | | |
| | | |<----- NOTIFY F16<|
| | | | |
| | | |>F17 200 OK ----->|
| | |<- NOTIFY F18<| |
| | | | |
| | |>F19 200 OK ->| |
| | | |------ NOTIFY F20>|
| | | | |
| | | |<F21 200 OK -----<|
|>F22 180 --->| | | |
| |>F23 180 Ringing ------------------------------->|
| | | | |
| | | |<----- NOTIFY F24<|
| | | | |
| | | |>F25 200 OK ----->|
| | |<- NOTIFY F26<| |
| | | | |
| | |>F27 200 OK ->| |
| | | |------ NOTIFY F28>|
| | | | |
| | | |<F29 200 OK -----<|
|>F30 200 OK ->| | | |
| |>F31 200 OK ------------------------------------>|
| | | | |
| | | |<----- NOTIFY F32<|
| | | | |
| | | |>F33 200 OK ----->|
| | | | |
| |<--------------------------------------- ACK F34<|
|<---- ACK F35<| | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| | |<- NOTIFY F36<| |
| | | | |
| | |>F37 200 OK ->| |
| | | |------ NOTIFY F38>|
| | | | |
| | | |<F39 200 OK -----<|
| | | | |
| | | |<----- NOTIFY F24<|
| | | | |
| | | |>F25 200 OK ----->|
| | |<- NOTIFY F26<| |
| | | | |
| | |>F27 200 OK ->| |
| | | |------ NOTIFY F28>|
| | | | |
| | | |<F29 200 OK -----<|
|>F30 200 OK ->| | | |
| |>F31 200 OK ------------------------------------>|
| | | | |
| | | |<----- NOTIFY F32<|
| | | | |
| | | |>F33 200 OK ----->|
| | | | |
| |<--------------------------------------- ACK F34<|
|<---- ACK F35<| | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| | |<- NOTIFY F36<| |
| | | | |
| | |>F37 200 OK ->| |
| | | |------ NOTIFY F38>|
| | | | |
| | | |<F39 200 OK -----<|
| | | | |
Figure 13. Appearance Agent Subscription to UAs Example
图13。对UAs的外观代理订阅示例
In this scenario, Bob has an established dialog with Carol created using the call flows of Figure 1 or Figure 2. Bob then places Carol on hold. Alice receives a notification of this and renders this on Alice's UI. Alice attempts to pick up the call but Carol hangs up before the pickup can complete. Alice cancels the pickup attempt with the PUBLISH F48. Note that the call flow for a failed Join would be almost identical.
在这个场景中，Bob使用图1或图2的调用流与Carol建立了一个对话。然后鲍勃让卡罗尔等着。Alice收到此通知并在Alice的UI上呈现此信息。爱丽丝试图接电话，但卡罗尔在接电话结束前挂断了电话。Alice使用发布F48取消拾取尝试。请注意，失败联接的调用流几乎相同。
Carol Proxy Alice Appearance Agent Bob
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| |<------------------------------(hold) INVITE F22<|
|<- INVITE F23<| | | |
Carol Proxy Alice Appearance Agent Bob
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| |<------------------------------(hold) INVITE F22<|
|<- INVITE F23<| | | |
| | | | |
|>F24 200 OK ->| | | |
| |>F25 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F26<|
|<---- ACK F27<| | | |
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F28<| |
| | | | |
| | |>F29 200 OK ->| |
| | | |>F30 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F31<|
| | | | |
| | Alice decides to pick up the call |
| | | | |
| | |>F32 PUBLISH->| |
| | | | |
| | |<- 200 OK F33<| |
| | | | |
| | |<- NOTIFY F34<| |
| | | | |
| | |>F35 200 OK ->| |
| | | |>F36 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F37<|
|>F38 BYE ---->| | | |
| |>F39 BYE --------------------------------------->|
| | | | |
| |<------------------------------------ OK 200 F40<|
|<- 200 OK F41<| | | |
| |<-- INVITE F42<| | |
|<- INVITE F43<|(w/ Replaces) | | |
|( w/ Replaces)| | | |
| | | | |
|>F44 481 ---->| | | |
| |>F45 481 ----->| | |
|<---- ACK F46<| | | |
| |<----- ACK F47<| | |
| | |>F48 PUBLISH->| |
| | | | |
| | |<- 200 OK F49<| |
| | | | |
| | |<- NOTIFY F50<| |
| | | | |
| | |>F51 200 OK ->| |
| | | | |
|>F24 200 OK ->| | | |
| |>F25 200 OK ------------------------------------>|
| | | | |
| |<--------------------------------------- ACK F26<|
|<---- ACK F27<| | | |
| | | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |<- NOTIFY F28<| |
| | | | |
| | |>F29 200 OK ->| |
| | | |>F30 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F31<|
| | | | |
| | Alice decides to pick up the call |
| | | | |
| | |>F32 PUBLISH->| |
| | | | |
| | |<- 200 OK F33<| |
| | | | |
| | |<- NOTIFY F34<| |
| | | | |
| | |>F35 200 OK ->| |
| | | |>F36 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F37<|
|>F38 BYE ---->| | | |
| |>F39 BYE --------------------------------------->|
| | | | |
| |<------------------------------------ OK 200 F40<|
|<- 200 OK F41<| | | |
| |<-- INVITE F42<| | |
|<- INVITE F43<|(w/ Replaces) | | |
|( w/ Replaces)| | | |
| | | | |
|>F44 481 ---->| | | |
| |>F45 481 ----->| | |
|<---- ACK F46<| | | |
| |<----- ACK F47<| | |
| | |>F48 PUBLISH->| |
| | | | |
| | |<- 200 OK F49<| |
| | | | |
| | |<- NOTIFY F50<| |
| | | | |
| | |>F51 200 OK ->| |
| | | |>F52 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F53<|
| | | |>F52 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F53<|
Figure 14. Appearance Pickup Race Condition Failure Example
图14。外观拾取竞争条件故障示例
F48 Alice ----> Appearance Agent
F48 Alice ----> Appearance Agent
PUBLISH sip:HelpDesk@example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A From: <sip:alice@example.com>;tag=44150CC6-A7B7919D To: <sip:HelpDesk@example.com>;tag=428765950880801 CSeq: 11 PUBLISH Call-ID: 87837Fkw87asfds Contact: <sip:alice@ua2.example.com> Event: dialog;shared Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: ...
发布sip：HelpDesk@example.comSIP/2.0 Via:SIP/2.0/UDP ua2.example.com；分支=z9hG4bKa5d6cf61F5FBC05A来自：alice@example.com>;标签=44150CC6-A7B7919D至：<sip:HelpDesk@example.com>;tag=4287659508801 CSeq:11发布呼叫ID:87837Fkw87asfds联系人：<sip:alice@ua2.example.com>事件：对话框；共享最大转发：70内容类型：应用程序/对话框信息+xml内容长度：。。。
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10"
state="full"
entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83"
call-id="dc95da63-60db1abd-d5a74b48"
local-tag="605AD957-1F6305C2" >
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<sa:replaced-dialog
call-id="14-1541707345"
from-tag="44BAD75D-E3128D42"
to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" />
<state>terminated</state>
<local>
<target uri="sip:alice@ua1.example.com">
</target>
</local>
<remote>
<target uri="sip:carol@ua3.example.com" />
</remote>
</dialog>
</dialog-info>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
version="10"
state="full"
entity="sip:HelpDesk@example.com">
<dialog id="id3d4f9c83"
call-id="dc95da63-60db1abd-d5a74b48"
local-tag="605AD957-1F6305C2" >
<sa:appearance>1</sa:appearance>
<sa:exclusive>false</sa:exclusive>
<sa:replaced-dialog
call-id="14-1541707345"
from-tag="44BAD75D-E3128D42"
to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" />
<state>terminated</state>
<local>
<target uri="sip:alice@ua1.example.com">
</target>
</local>
<remote>
<target uri="sip:carol@ua3.example.com" />
</remote>
</dialog>
</dialog-info>
Alice tries to seize appearance 2 at the same time appearance 2 is allocated to an incoming call. The Appearance Agent resolves the conflict by sending a 400 (Bad Request) to Alice. After the NOTIFY F6, Alice learns that the incoming call is using appearance 2. Alice republishes for appearance 3, which is accepted. Note that this example shows the INVITE being received before the NOTIFY from the Appearance Agent.
Alice试图在外观2分配给传入呼叫的同时捕获外观2。外观代理通过向Alice发送400（错误请求）来解决冲突。在NotifyF6之后，Alice知道传入呼叫使用的是外观2。Alice重新发布外观3，这是可以接受的。请注意，此示例显示了在收到来自外观代理的通知之前收到的邀请。
Carol Proxy Alice Appearance Agent Bob
| | | | |
|>-- INVITE F1>| | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |>F2 PUBLISH ->| |
| | | (appearance=2) |
| | | | |
| |>F3 INVITE (appearance=2) ---------------------->|
| | | | |
| |>F4 INVITE | | |
| |(appearance=2)>| | |
| | |<---- F5 400 <| |
| | | | |
| | |<-- NOTIFY F6<| |
| | | | |
| | |>F7 200 OK -->| |
| | | |------- NOTIFY F8>|
| | | | |
| | | |<F9 200 OK ------<|
| | | | |
| | |>F10 PUBLISH->| |
| | | (appearance=3) |
| | | | |
| | |< F11 200 OK <| |
| | | | |
| | |<- NOTIFY F12<| |
| | | | |
| |>F13 200 OK ->| |
Dave | | |------ NOTIFY F14>|
| | | | |
| | | |<F15 200 OK -----<|
| |<-- INVITE F16<| | |
| | | | |
| |>F17 100 ----->| | |
|<- INVITE F18<| | | |
Carol Proxy Alice Appearance Agent Bob
| | | | |
|>-- INVITE F1>| | | |
| |< - - - - - - - - - - - - - ->| |
| | | | |
| | |>F2 PUBLISH ->| |
| | | (appearance=2) |
| | | | |
| |>F3 INVITE (appearance=2) ---------------------->|
| | | | |
| |>F4 INVITE | | |
| |(appearance=2)>| | |
| | |<---- F5 400 <| |
| | | | |
| | |<-- NOTIFY F6<| |
| | | | |
| | |>F7 200 OK -->| |
| | | |------- NOTIFY F8>|
| | | | |
| | | |<F9 200 OK ------<|
| | | | |
| | |>F10 PUBLISH->| |
| | | (appearance=3) |
| | | | |
| | |< F11 200 OK <| |
| | | | |
| | |<- NOTIFY F12<| |
| | | | |
| |>F13 200 OK ->| |
Dave | | |------ NOTIFY F14>|
| | | | |
| | | |<F15 200 OK -----<|
| |<-- INVITE F16<| | |
| | | | |
| |>F17 100 ----->| | |
|<- INVITE F18<| | | |
Figure 15. Appearance Seizure Incoming/Outgoing Contention Race Condition Example
图15。传入/传出争用竞争条件示例
Since multiple line appearance features are implemented using semantics provided by SIP [RFC3261], the SIP Event Package for Dialog State [RFC4235], and the SIP Event Framework [RFC6665] and [RFC3903], security considerations in these documents apply to this document as well.
由于多行外观功能是使用SIP[RFC3261]、对话框状态的SIP事件包[RFC4235]以及SIP事件框架[RFC6665]和[RFC3903]提供的语义实现的，因此这些文档中的安全注意事项也适用于本文档。
To provide confidentiality, NOTIFY or PUBLISH message bodies that provide the dialog state information and the dialog identifiers MAY be encrypted end-to-end using the standard mechanisms such as S/MIME described in [RFC3261]. Alternatively, sending the NOTIFY and PUBLISH requests over TLS also provides confidentiality, although on a hop-by-hop basis. All SUBSCRIBEs and PUBLISHes between the UAs and the Appearance Agent MUST be authenticated. Without proper authentication and confidentiality, a third party could learn information about dialogs associated with a AOR and could try to use this information to hijack or manipulate those dialogs using SIP call control primitives.
为了提供机密性，可以使用[RFC3261]中描述的标准机制（如S/MIME）对提供对话状态信息和对话标识符的通知或发布消息体进行端到端加密。或者，通过TLS发送NOTIFY和PUBLISH请求也可以提供机密性，尽管是逐跳的。UAs和外观代理之间的所有订阅和发布都必须经过身份验证。如果没有适当的身份验证和保密性，第三方可能会了解与AOR相关的对话框的信息，并可能试图使用SIP呼叫控制原语利用这些信息劫持或操纵这些对话框。
This feature relies on standard SIP call control primitives such as Replaces and Join. Proper access controls on their use MUST be used so that only members of the shared appearance group can use these mechanisms. All INVITEs with Replaces or Join header fields MUST only be accepted if the peer requesting dialog replacement or joining has been properly authenticated using a standard SIP mechanism (such as Digest or S/MIME), and authorized to request a replacement. Otherwise, a third party could disrupt or hijack existing dialogs in the shared appearance group.
此功能依赖于标准SIP呼叫控制原语，如替换和连接。必须对其使用进行适当的访问控制，以便只有共享外观组的成员才能使用这些机制。只有在请求对话框替换或加入的对等方已使用标准SIP机制（如Digest或S/MIME）正确验证并有权请求替换的情况下，才必须接受带有Replaces或Join header字段的所有邀请。否则，第三方可能会破坏或劫持共享外观组中的现有对话框。
For an emergency call, a UA MUST NOT wait for a confirmed seizure of an appearance before sending an INVITE. Waiting for confirmation could inadvertently delay or block the emergency call, which by its nature needs to be placed as expeditiously as possible. Instead, a emergency call MUST proceed regardless of the status of the PUBLISH transaction.
对于紧急呼叫，UA不得在发送邀请之前等待确认的出现。等待确认可能会无意中延迟或阻止紧急呼叫，因为紧急呼叫的性质需要尽快进行。相反，无论发布事务的状态如何，都必须进行紧急呼叫。
This section registers the SIP Event header field parameter 'shared', the SIP Alert-Info header field parameter 'appearance', and the XML namespace extensions to the SIP Dialog Package.
本节将SIP事件标头字段参数“shared”、SIP警报信息标头字段参数“appearance”和XML命名空间扩展注册到SIP对话包。
This document defines the 'shared' header field parameter in the Event header field in the "Header Field Parameters and Parameter Values" registry defined by [RFC3968].
本文档在[RFC3968]定义的“标题字段参数和参数值”注册表中的事件标题字段中定义了“共享”标题字段参数。
Predefined
Header Field Parameter Name Values Reference
---------------------------- ------------------ ---------- ---------
Event shared No RFC 7463
Predefined
Header Field Parameter Name Values Reference
---------------------------- ------------------ ---------- ---------
Event shared No RFC 7463
This document defines the 'appearance' parameter in the Alert-Info header in the "Header Field Parameters and Parameter Values" registry defined by [RFC3968].
本文档定义了[RFC3968]定义的“标题字段参数和参数值”注册表中警报信息标题中的“外观”参数。
Predefined
Header Field Parameter Name Values Reference
---------------------- --------------- --------- ---------
Alert-Info appearance No RFC 7463
Predefined
Header Field Parameter Name Values Reference
---------------------- --------------- --------- ---------
Alert-Info appearance No RFC 7463
This section registers a new XML namespace per the procedures in [RFC3688].
本节根据[RFC3688]中的过程注册一个新的XML命名空间。
URI: urn:ietf:params:xml:ns:sa-dialog-info.
URI:urn:ietf:params:xml:ns:sa对话框信息。
Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
Alan Johnston <alan.b.johnston@gmail.com>
Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
Alan Johnston <alan.b.johnston@gmail.com>
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Shared Appearance Dialog Information Namespace</title>
</head>
<body>
<h1>Namespace for Shared Appearance Dialog Information</h1>
<h2>urn:ietf:params:xml:ns:sa-dialog-info</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7463.txt">
RFC 7463</a>.</p>
</body>
</html>
END
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Shared Appearance Dialog Information Namespace</title>
</head>
<body>
<h1>Namespace for Shared Appearance Dialog Information</h1>
<h2>urn:ietf:params:xml:ns:sa-dialog-info</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7463.txt">
RFC 7463</a>.</p>
</body>
</html>
END
This section registers an XML schema per the procedures in [RFC3688].
本节根据[RFC3688]中的过程注册XML模式。
URI: urn:ietf:params:xml:schesa:sa-dialog-info.
URI:urn:ietf:params:xml:schesa:sa对话框信息。
Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
Alan Johnston <alan.b.johnston@gmail.com>
Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
Alan Johnston <alan.b.johnston@gmail.com>
The XML for this schema can be found in Section 6.
该模式的XML可以在第6节中找到。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003, <http://www.rfc-editor.org/info/rfc3515>.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月<http://www.rfc-editor.org/info/rfc3515>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月<http://www.rfc-editor.org/info/rfc3688>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004, <http://www.rfc-editor.org/info/rfc3840>.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 38402004年8月<http://www.rfc-editor.org/info/rfc3840>.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004, <http://www.rfc-editor.org/info/rfc3891>.
[RFC3891]Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了RFC 38912004年9月的“头”<http://www.rfc-editor.org/info/rfc3891>.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004, <http://www.rfc-editor.org/info/rfc3903>.
[RFC3903]Niemi，A.，“事件状态发布的会话启动协议（SIP）扩展”，RFC 3903，2004年10月<http://www.rfc-editor.org/info/rfc3903>.
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004, <http://www.rfc-editor.org/info/rfc3911>.
[RFC3911]Mahy，R.和D.Petrie，“会话启动协议（SIP）”加入“头”，RFC 3911，2004年10月<http://www.rfc-editor.org/info/rfc3911>.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004, <http://www.rfc-editor.org/info/rfc3968>.
[RFC3968]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理机构（IANA）头字段参数注册表”，BCP 98，RFC 3968，2004年12月<http://www.rfc-editor.org/info/rfc3968>.
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005, <http://www.rfc-editor.org/info/rfc4235>.
[RFC4235]Rosenberg，J.，Schulzrinne，H.，和R.Mahy，“会话启动协议（SIP）的邀请启动对话事件包”，RFC 42352005年11月<http://www.rfc-editor.org/info/rfc4235>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012, <http://www.rfc-editor.org/info/rfc6665>.
[RFC6665]Roach，A.，“SIP特定事件通知”，RFC 66652012年7月<http://www.rfc-editor.org/info/rfc6665>.
[RFC7462] Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and P. Kyzivat, "URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)", RFC 7462, March 2015, <http://www.rfc-editor.org/info/rfc7462>.
[RFC7462]Liess，L.，Ed.，Jeske，R.，Johnston，A.，Worley，D.，和P.Kyzivat，“会话启动协议（SIP）警报信息报头字段的URN”，RFC 7462，2015年3月<http://www.rfc-editor.org/info/rfc7462>.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004, <http://www.rfc-editor.org/info/rfc3680>.
[RFC3680]Rosenberg，J.，“用于注册的会话启动协议（SIP）事件包”，RFC 36802004年3月<http://www.rfc-editor.org/info/rfc3680>.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006, <http://www.rfc-editor.org/info/rfc4579>.
[RFC4579]Johnston，A.和O.Levin，“会话发起协议（SIP）呼叫控制-用户代理会议”，BCP 119，RFC 4579，2006年8月<http://www.rfc-editor.org/info/rfc4579>.
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008, <http://www.rfc-editor.org/info/rfc5359>.
[RFC5359]Johnston，A.，Sparks，R.，Cunningham，C.，Donovan，S.，和K.Summers，“会话启动协议服务示例”，BCP 144，RFC 5359，2008年10月<http://www.rfc-editor.org/info/rfc5359>.
[RFC7088] Worley, D., "Session Initiation Protocol Service Example -- Music on Hold", RFC 7088, February 2014, <http://www.rfc-editor.org/info/rfc7088>.
[RFC7088]Worley，D.，“会话启动协议服务示例——暂停音乐”，RFC 7088，2014年2月<http://www.rfc-editor.org/info/rfc7088>.
Acknowledgements
致谢
The following individuals were part of the shared appearance design team and have provided input and text to the document (in alphabetical order):
以下人员是共享外观设计团队的一部分，并为文件提供了输入和文本（按字母顺序排列）：
Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek MacDonald, Bill Mitchell, Michael Procter, and Theo Zourzouvillys.
马丁·多利、安德鲁·赫顿、拉吉·詹、费尔南多·伦巴多、德里克·麦克唐纳、比尔·米切尔、迈克尔·普罗克特和西奥·佐维利。
Thanks to Chris Boulton for helping with the XML schema.
感谢Chris Boulton对XML模式的帮助。
Much of the material has been drawn from previous work by Mohsen Soroushnejad, Venkatesh Venkataramanan, Paul Pepper, and Anil Kumar, who in turn received assistance from:
大部分材料来自Mohsen Soroushnejad、Venkatesh Venkataramanan、Paul Pepper和Anil Kumar之前的工作，他们反过来得到了以下方面的帮助：
Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems; Steve Towlson and Michael Procter of Citel Technologies; Rob Harder and Hong Chen of Polycom, Inc.; John Elwell and JD Smith of Siemens Communications; Dale R. Worley of Pingtel; and Graeme Dollar of Yahoo, Inc.
Sylantro系统公司的Kent Fritz、John Weald和Sunil Veluvali；Citel Technologies的Steve Towlson和Michael Procter；宝利通公司的Rob Harder和Hong Chen。；西门子通信公司的John Elwell和JD Smith；Pingtel的Dale R.Worley；和雅虎公司的格雷姆·多尔。
Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell, Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their comments.
还要感谢杰夫·迪瓦恩、保罗·基齐瓦特、杰瑞·尹、约翰·埃尔维尔、丹·约克、斯宾塞·道金斯、马丁·多利和布雷特·泰特的评论。
Thanks to Carolyn Beeton, Francois Audet, Andy Hutton, Tim Ross, Raji Chinnappa, and Harsh Mendiratta for their detailed review of the document.
感谢卡罗琳·贝顿、弗朗索瓦·奥德特、安迪·赫顿、蒂姆·罗斯、拉吉·钦纳帕和哈什·门迪拉塔对该文件的详细审查。
Authors' Addresses
作者地址
Alan Johnston (editor) Avaya St. Louis, MO United States
艾伦·约翰斯顿（编辑）美国密苏里州圣路易斯市阿瓦亚
EMail: alan.b.johnston@gmail.com
EMail: alan.b.johnston@gmail.com
Mohsen Soroushnejad (editor) Sylantro Systems Corp.
Mohsen Soroushnejad（编辑）Sylantro系统公司。
EMail: msoroush@gmail.com
EMail: msoroush@gmail.com
Venkatesh Venkataramanan Sylantro Systems Corp.
文卡特什·文卡特拉马南·西兰特罗系统公司。
EMail: vvenkatar@gmail.com
EMail: vvenkatar@gmail.com