[要約] RFC 7463は、SIPアドレスの共有外観を定義し、AORのセッション開始プロトコル（SIP）アドレスの共有を可能にするためのガイドラインです。このRFCの目的は、複数のユーザーが同じAORを共有できるようにすることです。
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)
Session Initiation Protocol（SIP）Address of Record（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.
このドキュメントでは、Bridged Line Appearance（BLA）、Multiple Line Appearance（MLA）、Shared Call / Line Appearance（SCA）として一般に知られているグループテレフォニー機能の要件と実装について説明します。 SIPには回線の概念がないため、Session Initiation Protocol（SIP）を使用して実装された場合、それはレコードのアドレス（AOR）の共有外観と呼ばれます。この機能は、一般にIP CentrexサービスとIP構内交換機（IPBX）で提供され、ビジネス環境で使用されるSIP IP電話とSIP機能サーバーに実装される可能性があります。この機能により、複数のユーザーエージェント（UA）が共通のAORを共有し、グループ内の他のUAが発信および受信した通話について学習し、グループ内の通話をピックアップまたは参加できます。このドキュメントでは、ユースケースについて説明し、要件を示し、この機能を実装するための拡張機能を定義します。この仕様は、RFC 3261および4235を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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 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ユーザーエージェント（UA）の機能要件は、サービスとエンドユーザーエクスペリエンスの両方の点で、基本的なSIP UAとは大きく異なります。基本的なSIPサポート[RFC3261]に加えて、ビジネス環境の多くのサービスでは、REFER [RFC3515]、SUBSCRIBE / NOTIFY [RFC6665]、PUBLISH [RFC3903]、SIP Replaces [RFC3891]などのSIP拡張のサポートが必要です。および結合[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.
この仕様では、ビジネス環境でSIP IPテレフォニーデバイスに期待されるより一般的な高度な機能の1つである、Bridged Line Appearance（BLA）またはMultiple Line Appearances（MLA）としてテレフォニーでさまざまに知られているグループテレフォニー機能を実装する方法について詳しく説明します。この機能のその他の名前には、共有通話/回線の外観（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.
このドキュメントでは、UA間でステータスを交換するために、SIPイベント[RFC6665]およびパブリケーション[RFC3903]（SIPダイアログ状態イベントパッケージ[RFC4235]を伝送）とともに標準SIP [RFC3261]を使用してこの機能を実装する方法について説明します。
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（Address of Record）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. 人間のユーザーはこの概念に慣れており、代替システムでそれを期待します（たとえば、オーバーヘッドページの発表には「ジョーピックアップライン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.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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を共有できます。たとえば、5人のIT部門のスタッフが、IT作業領域の各電話で3つの外観を持つヘルプラインに応答するとします。ある電話で応答された通話を保留にして、別の電話でピックアップすることができます。別のスタッフメンバーへの叫びまたはIMにより、特定の外観のコールが引き継がれる場合があります。別の電話が既存の外観への追加/参加/ブリッジを要求して、電話会議を行うことができます。
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.
このシナリオでは、着信呼び出しはUAのグループに提供されます。 1人が応答すると、他のUAに通知されます。グループ内の別の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.
ユーザーが1つの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への着信呼び出しは、UAのグループに提供される必要があり、UAのいずれかによって応答できます。
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に登録するUAは、グループメンバーを手動で構成しなくても、共有外観グループに参加できる必要があります。
REQ-5: The mechanism must scale for large numbers of appearances and large numbers of UAs without introducing excessive messaging traffic.
REQ-5：メカニズムは、過剰なメッセージングトラフィックを導入することなく、多数のアピアランスと多数のUAに対応する必要があります。
REQ-6: Each call or session (incoming or outgoing) should be assigned a common "appearance" number from a managed pool 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.
REQ-6：各コールまたはセッション（着信または発信）には、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：グループ内のUA間の外観の競合を解決するメカニズムが必要です。このコンテキストでの競合は、混合されていない、または関連付けられていない複数のダイアログに関連付けられている外観番号を意味します。
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：メカニズムは、着信セッション要求を受信するすべてのUAがアラート時に同じ外観番号を利用できるようにする必要があります。
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：このメカニズムでは、グループ外のUAが外観番号を選択、強制、または操作することを許可してはなりません。
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：プライバシー上の理由から、外観情報がUAのグループの外に漏洩しないようにするメカニズムが必要です（たとえば、「だれが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：このメカニズムは、UAがラインアピアランスで排他性を要求する方法をサポートする必要があります。排他性とは、それを要求しているUAが外部の当事者とのプライベートな会話を望んでいることを意味し、他のUAは参加または通話を許可されてはならない排他性は、着信または発信セッションの開始時、またはセッション中に要求される場合があります。排他的要求は、共有外観サービスを提供するエンティティによって受け入れられるか、拒否される可能性があります。したがって、メカニズムはリクエスタ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 Dialog PackageはREQ-2を満たしています。
o The combination of the SIP Replaces and Join header fields meets REQ-3.
o SIP ReplacesおよびJoinヘッダーフィールドの組み合わせは、REQ-3に適合しています。
o The use of a State Agent for the Dialog Package meets REQ-4 and REQ-5.
o Dialog PackageのState Agentの使用は、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.
外観リソースは集中管理なしでUAのグループによって協調的に管理できますが、これはこのドキュメントの範囲外です。また、Appearance Agentロジックがグループ内のすべてのUAに分散される可能性もあります。たとえば、着信要求への外観番号の割り当てを制御するルール（たとえば、利用可能な最小の外観番号）と競合処理のルール（たとえば、2つのUAが同じ外観番号の使用を要求した場合、ダイアログ識別子をハッシュし、勝った最低のハッシュと比較します。 ）定義して実装する必要があります。
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 lost, a UA in the group might receive an incoming INVITE but might not know which appearance number to render during alerting.
REQ-9に最適に対応するには、着信INVITEの外観番号をダイアログパッケージNOTIFYで配信することに加えて、INVITEに含める必要があります。それ以外の場合、NOTIFYが遅延または失われると、グループ内のUAは着信INVITEを受信する可能性がありますが、アラート中にどの外観番号をレンダリングするかわからない場合があります。
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のAlert-Infoヘッダーフィールドが外観番号を伝えるために、セクション7で規範的に定義されている拡張パラメーターを定義しています。
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. グループ内の他のUAのダイアログ状態について学習した情報は、ユーザーに表示されます。
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. 着信コールはグループ内のすべてのUAに分岐され、誰でも応答できます。 UAは、Appearance AgentからのNOTIFYとINVITE自体で着信コールをレンダリングする際に使用する外観番号を受け取ります。 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応答を待ってからINVITEを送信します。
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. 発信コールの場合、ユーザが特定の外観を取得しないか気にしない場合、INVITEをすぐに送信でき、外観エージェントからの通知からコールが進行するにつれて、外観番号が学習されます。
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 also publishes prior to sending the INVITE but does not include an appearance number in the publication.
7.発信コールの場合、ユーザーが外観番号の割り当てを望まない場合（コンサルテーションコール中、またはUAが保留音[RFC7088]などの「サービスメディア」をフェッチしている場合）、UAは送信前に発行します。 INVITE。ただし、パブリケーションに外観番号は含まれません。
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によって参加（ブリッジ）または取得（ピック）されます。ダイアログパッケージ通知の情報を使用して、JoinまたはReplacesヘッダーフィールドを作成できます。これらのタイプの操作には同じ外観番号が使用されるため、この情報は、INVITE JoinまたはINVITE Replacesを送信する前に公開されます。
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. 外観エージェントは、グループ内の一部またはすべてのUAの完全なダイアログ状態に直接アクセスできない場合があります。この場合、アピアランスエージェントは、グループ内の個々のUAのダイアログ状態をサブスクライブして、この情報を取得します。いずれの場合でも、Appearance Agentは、AORの総ダイアログ状態が変化するたびに、呼び出しが行われた、応答された、保留された、保留された、ハングした場合など、通常の通知を（ステップ1でUAによって確立されたサブスクリプションを介して）送信しますアップ。
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の1つ以上のダイアログに関連付けられている正の整数です。外観番号は、外観エージェントによって管理され、この仕様をサポートするUAによってユーザーに表示およびレンダリングされます。外観番号が割り当てられるか要求されると、通常、割り当てられた番号は、この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.
捕捉：外観を捕捉することにより、電話をかける前に外観を予約できます。あたかもダイアログを開始しているかのように見せるために、実際にダイアログを開始する（つまり、INVITEを送信する）前に「試行」の人工的な状態を伝えることによって、外観を捕捉できます。
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.
選択（または非占有）：ダイアログを開始する前に「試行」という人工的な状態のそのような通信がない場合、外観は単に選択されます（つまり、捕捉されません）。つまり、ダイアログが実際に開始されたときに状態が通信されます。 。出現番号は、INVITEの送信後に学習されます。
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ダイアログイベントパッケージのパブリケーション、サブスクリプション、通知をサポートするUA、および共有の外観ダイアログパッケージの拡張と動作。
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]の拡張として4つの新しい要素を定義しています。スキーマはセクション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.
<dialog>要素の子である<appearance>要素は、親<dialog>要素によって記述されるダイアログの外観番号を伝えるために使用されます。 UAが親<dialog>のPUBLISHで状態属性 "trying"を付けてAppearance Agentに送信した場合、UAは指定されたダイアログIDを使用して、現在または将来のダイアログへの指定された外観番号の割り当てを要求しています。 <appearance>要素がNOTIFYでAppearance Agentから送信された場合、指定されたダイアログに外観番号が割り当てられていることを示しています。
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 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.
<dialog-info>要素は、含まれている要求がUAまたは外観エージェントによって送信されたかどうかに関係なく、含まれているダイアログをUA（「entity」属性によって名前が付けられる）の観点から記述していることに注意してください。特に、UAが記述されたダイアログ内でリクエストを送信した場合、ToヘッダーフィールドURIは<remote> <identity>値と一致し、to-tagパラメーターはremote-tag属性と一致します。同様に、FromヘッダーフィールドURIは<local> <identity>値と一致し、from-tagパラメータはlocal-tag属性と一致します。
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は、<で記述されたダイアログをターゲットとするJoinまたはReplacesヘッダーフィールドを持つINVITEを受け入れる用意がないことを示します。 <exclusive>要素の親であるdialog>要素。たとえば、一部の共有アピアランスシステムでは、コールが保留中の場合にのみコールピックアップが許可されます。この場合、<exclusive>要素は、保留状態によって「排他的」な値が示されるのではなく、通話が保留されている場合は「false」に、保留されていない場合は「true」に設定する必要があります。
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>タグを設定するだけでなく、完全なダイアログ情報をAppearance Agentに報告することはできません。完全なダイアログ情報（Call-ID、remote-tag、およびlocal-tag）がないと、別のUAがJoinまたはReplacesヘッダーフィールドを構築できません。 UAは<exclusive>を "true"に設定できますが、このダイアログに関連するINVITE結合を拒否する準備ができている必要があります。これらのダイアログ識別子がすでにAppearance Agentと共有されている場合、UAはINVITE Replacesを送信してそれらを変更し、新しいものをAppearance Agentに報告しません。
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 Replacesリクエストを403（Forbidden）応答で拒否することにより、この排他性を適用できます（MAY）。
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 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.
<dialog>要素の子である<joined-dialog>要素は、ダイアログと結合（混合またはブリッジ）された他のダイアログのダイアログ識別子を伝えるために使用されます。この要素をAppearance Agentへのパブリケーションに含める必要があるのは、混合ダイアログの共通のエンドポイントである（したがって混合操作を制御する）UAだけです。ダイアログを結合するためにJoinヘッダーフィールドが使用されなかった場合でも、この要素を引き続き使用する必要があることに注意してください。たとえば、UA上の2つの個別のダイアログを、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.
<dialog>要素の子である<replaced-dialog>要素は、このダイアログで置き換えられる、または置き換えられる他のダイアログのダイアログ識別子を伝えるために使用されます。たとえば、Replacesを指定してINVITEを送信することで別の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.
共有の外観機能をサポートするUAは、セクション13で定義された共有の外観拡張機能と「共有」イベントヘッダーフィールドパラメーターを持つダイアログ状態パッケージ[RFC4235]を使用します。
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.
UAは、セクション5.2のダイアログパッケージ拡張を、SUBSCRIBE [RFC6665]、NOTIFY [RFC6665]、およびPUBLISH [RFC3903]とともに使用します。ダイアログイベントパッケージのSUBSCRIBE、NOTIFY、およびPUBLISHリクエストには、この仕様で要求されている「共有」イベントヘッダーフィールドパラメータが含まれています。
The presence of the 'shared' Event header field parameter tells the Appearance Agent that the UA supports this specification.
「共有」イベントヘッダーフィールドパラメータの存在は、UAがこの仕様をサポートすることをAppearance Agentに通知します。
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]に従ってサブスクリプションを更新する必要があります。 SUBSCRIBE要求が失敗した場合、外観エージェントが存在しない可能性があり、この機能はこのAORに対してアクティブではありません。 UAは定期的にサブスクリプションを再試行して、4時間以上の間隔で状態が変化したかどうかを確認できます。
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あたりのサブスクリプションテストを1日あたり6回に制限するために、4時間が選択されました。この間隔を長くすると、この失敗のトラフィックは減少しますが、新しくアクティブ化された外観エージェントが検出されるまでに時間がかかります。
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.
UAは、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.
共有外観機能、コールピックアップ、参加、およびブリッジを実装するUAは、INVITEをReplaces [RFC3891]またはJoin [RFC3911]で送信することをサポートする必要があります。ユーザーエージェントクライアント（UAC）は、RFC 3891および3911のルールに従ってユーザーエージェントサーバー（UAS）によって正しいダイアログが照合されるように、置換または結合ヘッダーにto-tagおよびfrom-tag情報を含める必要があります。
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.
共有の外観機能を実装し、INVITEをサポートするすべてのUAは、Replaces [RFC3891]またはJoin [RFC3911]ヘッダーフィールドでのINVITEの受信をサポートする必要があります。
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には、公開時に利用可能なダイアログIDの最大のセットが含まれます。ただし、他のUAが通話に参加したりピックアップしたりできないようにする場合、UAは情報を省略できます。ダイアログの識別には、ローカルおよびリモートのターゲットURI、call-id、to-tag、from-tagが含まれます。このダイアログ識別情報は[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.
グループ内の他のUAのアイドル/アクティブ/アラート/ホールド状態の正確なレンダリングは、外観共有機能の重要な部分です。
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は、通常どおりINVITEを送信してアウトバウンドコールを発信します。
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はINVITEを送信する前に確認された発作を待たないでください。代わりに、緊急コールは、PUBLISHトランザクションを待たずに続行する必要があります。
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はダイアログパッケージPUBLISH要求を送信し、2xx応答を待ってからINVITEを送信する必要があります。これは、次の状況で必要です。
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タグとCall-IDが最初のPUBLISHに存在しなかった場合、この情報が利用可能になり次第、新しいPUBLISHを送信する必要があります。
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の外観番号を予約します。パブリケーションにダイアログ識別子（たとえば、Call-IDまたはlocal-tag）がない場合、外観エージェントは、いくつかのダイアログ識別子を含む2番目のパブリケーションまで、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ダイアログの状態を学習することを前提としています。この仕様では、PUBLISHを使用して、目的の意図した外観番号の操作を示します。ダイアログが早期から確認済みに移行すると、この役割は終了します。したがって、パブリケーションを更新する必要はありません。
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 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.
外観番号は、AORに関連するアクティブなダイアログと保留中のダイアログの省略ラベルです。この拡張機能を使用して構築された機能とサービスの多くは、ユーザーへのこの情報の正しいレンダリングに依存しています。さらに、機能のグループの性質は、レンダリングが異なるベンダーと異なるモデル間で類似している必要があることを意味します。そうしないと、これらのプロトコル拡張の価値と有用性が大幅に低下します。この機能の適切に設計されたユーザーインターフェイスでは、アクティブおよび保留中の各ダイアログの外観番号は、明示的（つまり、外観番号による）または暗黙的（ユーザーに番号と順序を明確にするユーザーインターフェイスのメタファーを使用）で、ユーザー。各ダイアログの遠端のアイデンティティ（リモートパーティのアイデンティティなど）は、外観番号の代わりに使用することはできません。各外観の状態もレンダリングされます（アイドル、アクティブ、ビジー、結合など）。 UAは、他のSIPダイアログ識別子を含む1つ以上の<joined-dialog>要素の存在によって、一連のダイアログが結合（ブリッジまたは混合）されていることを通知できます。ダイアログの外観番号は、<appearance>要素を含むダイアログパッケージ通知によって、Appearance Agentまたは着信INVITEの 'appearance' Alert-Infoパラメータから取得できます。それらが競合する場合、ダイアログパッケージ通知が優先されます。
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]で説明されているように、PUBLISHを使用してイベント状態を削除することにより、外観番号を解放します。これに失敗すると、Appearance Agentによる不必要な操作が必要になり、共有の外観グループ内の他のUAが使用する可能性のある外観番号を関連付けます。
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に対して登録する必要があります（SHOULD）。 UAが主に共有の外観グループコールのステータスを監視し、コールを選択または参加する場合、UAはAORにサブスクライブするだけで、AORに登録しないでください。モニタリングUAが単にサブスクライブするのではなく登録すると、大量の不要なネットワークトラフィックが生成されます。
All subscribed UAs will receive dialog package NOTIFYs of trying state for incoming INVITEs.
すべてのサブスクライブされたUAは、着信INVITEの試行状態のダイアログパッケージNOTIFYを受け取ります。
A UA MUST NOT insert an 'appearance' parameter into an Alert-Info header field in an INVITE or other request.
UAは、INVITEまたはその他のリクエストのAlert-Infoヘッダーフィールドに「外観」パラメーターを挿入してはなりません（MUST NOT）。
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 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.
UAの2つの別々のダイアログが混合されず、同じ「コンテキスト」を共有する場合があります。つまり、これらは互いに関連しているため、グループ内の他の2つのダイアログと同じように扱うべきではありません。この1つの例は、ユーザーが既存のダイアログを保留にしてから、元のダイアログに切り替える前に別のユーザーを呼び出す「コンサルトコール」です。以下に説明する別のケースは、転送操作中に発生します。一時的な期間では、UAは他の2つのUAとのダイアログに関与しますが、ダイアログは関連しているため、独立したダイアログとして扱うべきではありません。これらのケースは、既存のダイアログとコンテキストを共有するときに、新しく作成されたダイアログに外観番号を割り当てないことで最も適切に処理されます。ただし、既存のダイアログが終了した場合は、その外観番号を新しく作成されたダイアログに再度割り当てる必要があります。
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は、INVITEを送信する前にPUBLISHを送信します。 PUBLISHには「appearance」要素はありませんが、「shared」イベントヘッダーフィールドパラメータはあります。外観エージェントのポリシーで外観番号が割り当てられていない通話が許可されていない場合、外観エージェントによって400（不正なリクエスト）応答が送信され、UAは外観番号を選択/捕捉するか、公開せずにINVITEを送信します。外観エージェントが割り当てます。
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:
ブリッジまたは呼び出しを試みるためにINVITEが生成された場合（つまり、JoinまたはReplacesが共有の外観グループ内の別のダイアログのダイアログ識別子に含まれている場合）、UAは最初にPUBLISHをAppearance Agentに送信する必要があります。この発行には以下が含まれます：
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ヘッダーフィールドからのダイアログ情報
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.
この情報はAppearance Agentに提供されるため、適切な外観の割り当て動作を提供できることに注意してください。最初に公開せずにINVITEのJoinまたはReplacesが送信された場合、Appearance AgentはこのINVITEに新しい外観番号を割り当てる可能性がありますが、これは誤りです。結合の場合、パブリケーションには<joined-dialog>要素が含まれ、外観番号の再利用が原因でAppearance Agentが400（Bad Request）応答を生成しないようにします。 Replacesの場合、<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).
転送操作中は、操作中に外観番号が変更されないことが重要です。共有の外観グループのメンバーであり、共有の外観グループの外にいるキャロルと話しているアリスの例を考えてみましょう。キャロルはアリスを、同じく共有されている外見グループの外にいるデイビッドに転送します。たとえば、アリスがキャロルとのセッションに外観3を使用している場合、結果として生じるデビッドとのセッションも外観番号3を使用する必要があります。 RFC 5589の用語を使用したシナリオは2つあります。アリスは、あらゆるタイプの転送の被転送者（REFERを受信）または在席転送の転送ターゲット（INVITEを置換で受信）です。
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.
アリスが譲受人である場合、REFERからトリガーされたINVITEはコンサルトコールとして扱われます。アリスは、アピアランスエージェントがこのINVITEにアピアランス番号を割り当てないように要求して発行する必要があります（SHOULD）。転送が完了すると、アリスは再度パブリッシュして外観番号をキャロルとのダイアログからデビッドとのダイアログに移動する必要があります（SHOULD）。外観番号を移動するためにPUBLISHを送信する場合は、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ヘッダーフィールドが含まれます。その結果、外観エージェントはキャロルとのダイアログの外観番号を再利用し、この外観番号はキャロルとのダイアログが終了した後も引き続き使用されます。
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に対して登録されたUAのダイアログパッケージ状態エージェントを実装する必要があります。外観エージェントは、セクション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に関連付けられたすべてのダイアログの状態を検出する方法を備えている必要があります。この情報がコールステートフルプロキシまたはBack-to-Back User Agent（B2BUA）から利用できない場合、Appearance Agentは登録イベントパッケージ[RFC3680]を使用して、AORに関連付けられたUAを学習し、ダイアログイベント状態にサブスクライブできます。 。外観エージェントは、状態を再構築するために、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グループのUAに次のイベントが発生するたびに、ダイアログイベント状態通知を送信する必要があります（SHOULD）。
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にサブスクライブしているUAに即時通知を送信する必要があります。 JoinまたはReplacesヘッダーフィールドを持つ着信INVITEを除いて、新しい外観番号が割り当てられます。この場合、外観番号は、結合または置換されるダイアログの外観番号と一致する必要があります。 INVITE ReplacesまたはJoinが共有の外観グループの外部からのものである場合、Appearance Agentは、ReplacesまたはJoinedヘッダーフィールドからのダイアログ情報を含むNOTIFYに<joined-dialog>または<replaced-dialog>要素を含めます。
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.
Appearance Agentは、フォーキングプロキシと通信して着信コールについて学習し、プロキシに外観番号を渡すか、適切な外観番号のAlert-InfoヘッダーフィールドがINVITEに含まれていることを確認する必要があります。
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.
UAは、アピアランス番号が割り当てられていない着信INVITEを処理できる必要があることに注意してください。これは、外観エージェントの障害またはその他のエラー状態が原因である可能性があります。 INVITEを適切にレンダリングできない場合もありますが、INVITEを無視したり、失敗したりするよりも、この方法の方が優れています。
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.
外観エージェントは、特定の外観番号を選択/取得するPUBLISHが受信されなかった場合に、送信ダイアログに外観番号を割り当てる必要があります（SHOULD）。
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.
共有された外観グループに外観を認識しないUAが呼び出しを行っている場合、外観エージェントはそれらのUAから送信されたINVITEに外観番号を割り当てます。
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> 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.
外観番号付きのPUBLISHを受け取る外観エージェントは、パブリケーションが有効であることを確認します。ダイアログが置換または結合されることを示す<joined-dialog>または<replaced-dialog>要素がない限り、外観番号は1つのダイアログにのみ割り当てることができます。選択された外観番号が無効な場合、400（Bad Request）応答が返され、完全なダイアログイベント状態を含むUAに即時のNOTIFYを送信する必要があります（SHOULD）。
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.
外観番号なしで「共有」イベントヘッダーフィールドパラメータが存在するPUBLISHを受信する外観エージェントは、これをUAによる外観番号を割り当てないようにとの要求として解釈します。 Appearance Agentポリシーがこれを許可しない場合、400（Bad Request）応答が返されます。ポリシーでこれが許可されている場合、200（OK）応答が返され、外観番号は割り当てられません。情報は他のUAによってレンダリングされないため、Appearance Agentはこのダイアログ情報をグループ内の他のUAと共有する（つまり、NOTIFYを送信する）必要はありません。
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].
Appearance Agentは、PUBLISHを介して外観が要求されたときから、またはINVITEの受信から、結合または置換されたすべてのダイアログを含む、外観に関連付けられた最後のダイアログが終了するまで、ダイアログに外観番号を割り当てます。初期のダイアログ状態の間、Appearance Agentは、PUBLISH要求に対する200（OK）応答のExpiresヘッダーフィールドを使用して、ダイアログ状態の公開率を制御します。 3分の間隔をお勧めします。パブリケーションに関連付けられたダイアログが確認された後、パブリケーション状態の期限切れは外観の割り当てに影響を与えません。パブリケーションにダイアログ状態情報が含まれていない場合、外観エージェントはUAの外観番号を予約する必要がありますが、UAの特定のダイアログに外観を割り当てることはできません。パブリケーションの状態がダイアログ情報で更新されると、外観番号を特定のダイアログに割り当てることができます。 [RFC3903]で説明されているように、PUBLISHを使用して出現番号が割り当てられたUAは、PUBLISHでイベント状態を削除することにより、出現番号を解放する場合があります。
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.
グループのメンバーがINVITEを共有AORに送信する場合（つまり、自分のAORを呼び出す場合）、外観エージェントは2つの外観番号を割り当てる必要があります。最初の出現番号は、発信INVITEに選択または割り当てられたものです。 2番目の外観番号は、グループのメンバーにフォークされるため、INVITEの外観エージェントによって割り当てられる別の番号になります。
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.
INVITEが共有AORを使用してグループのメンバーによって送信された場合、または共有AORに送信された場合、使用可能な外観番号がない場合、プロキシは403（禁止）応答コードでINVITEを拒否してもよい（MAY）。
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に関連付けられた1つ以上のUAが参加者であるダイアログでのみ使用されます。グループAORへの着信INVITEが別の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:
'appearance'、 'joined-dialog'、 'replaced-dialog'、および 'exclusive'要素は、新しいXML名前空間URI内で定義されます。この名前空間は「urn：ietf：params：xml：ns：sa-dialog-info」です。これらの要素のスキーマは次のとおりです。
<?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="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="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]を拡張して、 'appearance'パラメータをAlert-Infoヘッダーフィールドに追加し、プロキシがAlert-Infoヘッダーフィールドを変更または削除できるようにします。
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
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.
「外観」のAlert-Infoパラメータを挿入するプロキシは、通常のAlert-Infoポリシーに従います。このダイアログの外観番号を示すために、プロキシは 'appearance'パラメータを含むAlert-InfoヘッダーフィールドをINVITEに追加します。 Alert-Infoがすでに存在する場合、プロキシは「appearance」パラメータをAlert-Infoヘッダーフィールドに追加します。出現番号パラメーターがすでに存在する場合（別のAORに関連付けられているか、誤って）、値は新しい出現番号を追加して書き換えられます。 Alert-Infoヘッダーフィールドに複数の外観パラメーターがあってはなりません。
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]のように、Alert-Infoのurn：alert：service：normalを使用して通常の着信音を示す必要があります（SHOULD）。 Alert-Infoヘッダーフィールドに存在する外観番号は、セクション5.3のガイドラインに従って、UAによってユーザーに表示される必要があります（SHOULD）。 INVITEが別のAORに転送される場合、グループ外に転送する前に、Alert-Infoの外観パラメーターを削除する必要があります（SHOULD）。
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.
外観パラメーターで使用する値に関する決定は、登録されたすべてのUAへの着信要求をフォークするプロキシーで行うことができます。
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 group URI and escape the proper Alert-Info header field for the Proxy to recurse and distribute to the other UAs in the group.
プロキシーがこのパラメーターを設定するために使用する必要のある値をプロキシーが判別できるようにするさまざまな方法があります。たとえば、プロキシは、AORが使用中の行のリストをフェッチするために、Appearance Agentに対してExpires：0を指定したSUBSCRIBEリクエストを開始することで、この情報をフェッチできます。あるいは、共有された外観グループの一部であるUAのように動作し、他のUAと同様に状態エージェントにサブスクライブします。これにより、必要に応じてポーリングする必要なく、アクティブなダイアログ情報を利用できます。出現AORに分岐した、または出現AORから受信した一意のINVITEリクエストの数に基づいて、出現AORのアクティブコールのリストを追跡できます。別のアプローチは、プロキシが最初に着信INVITEをアピアランスエージェントに送信することです。これにより、共有アピアランスグループURIにリダイレクトし、プロキシが再帰してグループ内の他のUAに配布するための適切なAlert-Infoヘッダーフィールドをエスケープします。 。
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へのすべての着信要求について知る必要があります。これを行う1つの方法は、Appearance Agentがより高いq値でAORに対して登録することです。これにより、最初にINVITEがAppearance Agentに送信され、次にグループ内のUAに提供されます。
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.
UAによってユーザーインターフェイス機能が異なるため、一部のUAには他のUAにはない制限があることがよくあります。すべてのUA間での完全な相互運用性は明らかに不可能ですが、注意深い設計により、各UAの限界までの相互運用性を実現できます。
The following guidelines suggest how the appearance number should be handled in three typical user interface implementations.
次のガイドラインは、3つの一般的なユーザーインターフェイス実装での外観番号の処理方法を示しています。
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」の注釈が付いたメッセージを送信する必要があります（SHOULD）。番号「1」以外の外観の呼び出し指示は、480（一時的に使用不可）または486（ここでビジー）応答で拒否されるべきです（SHOULD）。これは、この呼び出しが2番目の外観番号を使用するため、単一の外観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.
これらのデバイスは、本質的に、コールウェイティングを実装する単一の外観の電話です。 2つの外観（トグルまたはフラッシュフック）とおそらく他の外観のステータスを示す可聴音を切り替えることができる非常にシンプルなユーザーインターフェイスを備えています。これらのUAで使用されるのは、外観番号「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」が割り当てられます。すべてのUAは、この呼び出しの到着をユーザーに表示できる必要があります。
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は、この呼び出しをユーザーに提示しないでください。他のUAは、最初の呼び出しとは異なり、この呼び出しを明確に提示するのに問題はありません。
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は、最初の外観以外の呼び出しを管理できないため、呼び出しがないことを示しているはずです。両方の共有された外観のUAは、外観番号「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 ensure that the presentation order is related to the appearance number and not the order of call arrival.
4. 3番目のコールが到着し、出現番号「1」が割り当てられます。すべてのUAは、この新しい呼び出しの到着をユーザーに表示できる必要があります。複数の外観のUAは、2番目の呼び出しの存在を示し続ける必要があり、また、プレゼンテーションの順序が呼び出しの到着順序ではなく、外観番号に関連していることを確認する必要もあります。
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.
共有の外観機能を実装するUAには、通常、グループ内の他の外観の状態を提供するユーザーインターフェイスがあります。外観エージェントからのダイアログ状態のNOTIFYが処理されると、この情報をレンダリングできます。最も単純なユーザーインターフェイスでさえ、通常はアイドル、アクティブ、保留の3つの状態があります。外観エージェントによって報告されるように、通常はランプオフで示されるアイドル状態は、外観番号がダイアログに関連付けられていないときに外観に対して示されます。通常はランプが点灯しているアクティブ状態は、外観エージェントから報告されるように、外観番号が少なくとも1つのダイアログに関連付けられていることを意味します。保留状態は、多くの場合、ランプの点滅によって示されますが、共有された外観グループ内の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を共有された外観グループの一部にすることが望ましい。これをサポートするには、プロキシはAppearance Agentと連携する必要があります。これは、基本的な共有の外観のアーキテクチャでは必要ありません。したがって、非共有の外観のUAとの共有の外観の相互運用性は、すべての共有の外観の展開で使用できるわけではありません。
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が結合または置換をサポートしない場合、これらのオプションが使用できないことを示すために、すべてのダイアログは「排他的」とマークされるべきです（SHOULD）。これらのダイアログを「排他的」にマークすると、ユーザーエクスペリエンスが向上し、余分なSIPメッセージングの失敗が回避されます。
In all cases, the Appearance Agent must be aware of the dialog lifetime to release appearances back into the group.
すべての場合において、Appearance Agentはダイアログの有効期間を認識して、外観をグループに戻す必要があります。
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.
また、ダイアログの状態の変更（保留など）は、Dialog Event Packageを介してグループ内の他のUAが利用できるようにすることも望まれます。外観エージェントが非共有の外観認識UAからのダイアログをRecord-Routesするプロキシを含む場合、外観エージェントは保留などのダイアログの状態を認識します。この情報は、エンド以外の検査から判断できます。 -to-end-encrypted INVITEおよびre-INVITEメッセージ、および他のUAに伝達されるダイアログ情報に追加されます。
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.
ダイアログイベントをサポートするが外観の共有機能をサポートしないUAとの相互運用性は、より簡単です。以前と同様に、すべての外観番号の割り当ては、外観エージェントが行う必要があります。外観エージェントは、NOTIFYに外観情報を含める必要があります（SHOULD）。このUAはこの追加情報を単に無視します。このタイプのUAは、外観番号の制限も無視し、排他とマークされたダイアログに参加または置換しようとする場合があります。その結果、プロキシまたはUAはそのような要求を拒否する必要があります。そうしないと、ダイアログが結合または取得されます。
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.
UAは、AORへのダイアログパッケージSUBSCRIBEへの応答で「共有」イベントヘッダーフィールドパラメーターを探すことにより、この機能が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のファーストパーティまたはサードパーティの登録を受け入れるように、レジストラをプロビジョニングする必要があります。ファーストパーティ登録は、REGISTERリクエストのToおよびFrom URIが共有AOR URIであることを意味します。サードパーティの登録とは、To URIが共有AOR URIであり、From URIが別のAORであり、おそらく個々のユーザーのAORであることを意味します。ドメインに設定されている承認ポリシーに応じて、共有AORの資格情報またはユーザーは、レジストラーとAppearance Agentによって受け入れられる必要があります。
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.
Appearance AgentがUAのダイアログ状態にサブスクライブする必要がある場合、UAがAppearance Agentを認証できるように、Appearance AgentとUAに資格情報をプロビジョニングする必要があります。
In some cases, UAs in the shared appearance group might have a UI limitation on the number of appearances that can be rendered.
場合によっては、共有される外観グループのUAは、レンダリングできる外観の数に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ではなく、ボタン/ランプを備えたハードフォンになります。この場合、Appearance Agentがこの最大数を知っていると便利です。これにより、Appearance Agentは、この制限に達したときにポリシーを適用できます（たとえば、呼び出しを拒否します）。ただし、このメカニズムはこれをプロトコル手段で発見する方法を提供しません。
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によって送信されたすべてのINVITEは共有AOR（この場合、sip：HelpDesk@example.com）からのものであり、グループに送信されたすべてのINVITEは、共有AOR。その他の要求はこの機能には適用されず、通常の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の例では、Appearance Agentがダイアログ状態イベントを認識していることを前提としています。セクション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.
ボブとアリスは、共有の外観AOR sip：HelpDesk@example.comで識別される共有の外観グループに属しています。連絡先sip：bob@ua2.example.comを使用するBob REGISTER。連絡先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.
アリスとボブのUAは、外観AORのダイアログパッケージにサブスクライブし、ダイアログの状態を外観エージェントにパブリッシュします。レジストラ、アピアランスエージェント、アリス、ボブの間のメッセージ交換を以下に示します。以下のコールフローの例は、サブスクリプション、パブリケーション、および通知の認証を示していません。セキュリティ上の理由から、すべてのパブリケーションとサブスクリプションは、承認される前に承認を受ける必要があることに注意してください。
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.
また、登録とサブスクリプションはすべて、レジストラまたはアピアランスエージェントによって返された有効期限間隔によって決定される間隔でアリスによって更新される必要があることに注意してください。
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<|
| | | |
Figure 1. Registration and Subscription Example
図1.登録とサブスクリプションの例
F1-F2: Alice registers AOR with
contact: <sip:alice@ua1.example.com>
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
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
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：アリスは、外観AORに関連付けられたイベントもサブスクライブします。アピアランスエージェントはアリスにステータスを通知します。
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
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
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 Content-Type: application/dialog-info+xml Event: dialog;shared Subscription-State: active;expires=3000 Contact: <sip:appearanceagent.example.com> Content-Length: ...
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 appearagent.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 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
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
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
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
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が共有の外観グループに属しています。キャロルは共有の外観グループAORに電話をかけます。アピアランスエージェントはアリスとボブにNOTIFYを送信し、コールが使用しているアピアランスを通知します。アリスとボブの両方のデバイスに着信が通知されます。ボブが電話に出ます。
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.
アリスとボブの両方がコールに応答し、キャロルに200（OK）応答を送信する可能性があることに注意してください。この状況を解決するのはキャロル次第です。通常、キャロルは両方の200 OKにACKを送信しますが、BYEを送信してダイアログの1つを終了します。その結果、アリスまたはボブのいずれかがBYEを受け取り、彼らのダイアログが終了したことを公開します。ただし、キャロルがアリスとボブの両方に応答し、両方のダイアログをアクティブにしておく場合、アピアランスエージェントは、アリスまたはボブのいずれかのダイアログを別の外観に移動して状況を解決する必要があります。
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 -<| | | |
| |<--------- 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
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: ...
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 appearagent.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：...
<?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>
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: ...
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
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: ...
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 appearagent.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：...
<?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は、最初に外観番号を選択/差し押さずに電話をかけます。ボブがINVITEを送信した後、アピアランスはアピアランス番号を割り当て、アリスとボブの両方に通知します。
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 -----<|
| | | | |
Figure 3. Outgoing Call without Appearance Seizure Example
図3.出現発作のない発信コールの例
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
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
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: ...
NOTIFY sip：alice@ua1.example.com SIP / 2.0 Via：SIP / 2.0 / UDP appearagent.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：...
<?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>
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: ...
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 appearagent.example.com; branch = z9hG4bK1711759878512309 Max-Forwards：70 Content-Type：application / dialog-info + xml Event：dialog; shared Subscription-State：active ; expires = 2000連絡先：<sip：appearanceagent.example.com> Content-Length：...
<?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 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.
このシナリオでは、BobのUAは、INVITEを送信する前に、出現番号を選択/捕捉する状態（試行中）のダイアログイベントPUBLISHを送信します。外観エージェントから外観番号を確認する200（OK）を受信すると、BobのUAはINVITEをキャロルに送信し、セッションを確立します。簡潔にするために、一部のメッセージの詳細はメッセージフローに含まれていません。 BobのUAは、F7からのダイアログ情報を、事前に決定できる限り多く入れます。この場合、最低限のContact URIが含まれているため、Appearance AgentはINVITEをPUBLISHと関連付けることができます。
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 -----<|
| | | | |
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：ボブは、UAのヘルプデスクの共有の外観を使用して、発信コールを発信します（オフフックにするなど）。発信INVITE要求を送信する前に、BobはAppearance Agentに公開番号1を予約して公開します。AppearanceAgentは、NOTIFYを送信することにより、イベントをアリス（およびBobを含む他のすべてのUA）に通知します。
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: ...
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コンテンツの長さ：...
<?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
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
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
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: ...
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コンテンツの長さ：...
<?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>
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.
このシナリオでは、ボブのUAは、状態（試行中）を含むダイアログイベントPUBLISHを送信して、このダイアログの外観番号を利用したくないことを示します。 PUBLISHには外観要素はありませんが、「共有」イベントヘッダーフィールドパラメータがあります。その結果、外観エージェントは、UAがこの呼び出しに外観番号を使用しないことを認識しています。 Appearance Agentがこれを許可しない場合、400（Bad Request）応答でPUBLISHを拒否し、UAは外観番号の選択/捕捉を再PUBLISHすることを認識します。
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 -----<|
| | | | |
Figure 5. Outgoing Call without using an Appearance Number Example
図5.外観番号の例を使用しない発信コール
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> Event: dialog;shared Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: ...
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-長さ：...
<?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.
ボブとキャロルはダイアログ内にあり、たとえばセクション11.3のように作成されます。 CarolはBYEをBobに送信してダイアログを終了し、Appearance Agentは使用されている外観番号の割り当てを解除し、共有グループ内のUAに通知を送信します。
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
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: ...
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 appearagent.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>コンテンツの長さ：...
<?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 pickup the dialog between Carol and Bob and, hence, may use the same appearance number. This example also shows Secure SIP (sips) being used.
このシナリオでは、ボブは図1または2のコールフローを使用して作成されたキャロルとの確立されたダイアログを持っています。ボブはキャロルを保留にします。アリスはこの通知を受け取り、これをアリスのUIに表示します。その後、アリスは保留中のコールをピックアップし、キャロルとの確立されたセッションを持ちます。最後に、キャロルは電話を切ります。アリスはF32をパブリッシュする必要があります。これは、INVITE F38がキャロルとボブの間のダイアログをピックアップする試みであるため、同じ外観番号を使用する可能性があることを示しています。この例は、使用されているセキュアSIP（sip）も示しています。
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<|
Figure 7. Appearance Pickup Example
図7.外観ピックアップの例
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: ...
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 appearagent.example.com; branch = z9hG4bK1403 Max-Forwards：70 Content-Type：application / dialog-info + xml Event：dialog; shared Subscription-State：active ; expires = 1800連絡先：<sips：appearanceagent.example.com> Content-Length：...
<?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>
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: ...
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：...
<?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>
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
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.
このシナリオでは、ボブは共有の外観グループにも属しているアリスに電話をかけます。このダイアログで使用される外観番号は1つだけです。この例では、「exclusive」タグを使用して、グループ内の他のUAがこのダイアログに参加または参加できないことを示しています。
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<|
| | | | |
Figure 8. Call between UAs within the Group Example
図8.グループ内のUA間の呼び出しの例
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: ...
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 appearagent.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：...
<?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>
<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>
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.
このシナリオでは、ボブがキャロルと通話しています。ボブは、キャロルを保留にしてアリスに電話することにより、アリスにコンサルトコールを発信します。ボブのUAはそれをキャロルへのコールの一部として処理しているため、アリスへのコールには出現番号を持たないことを選択します。彼はこれをPUBLISH F32で示しており、これには「共有」イベントヘッダーフィールドパラメータが含まれていますが、<appearance>要素は含まれていません。外観エージェントによって外観番号が割り当てられないようにするために、PUBLISHはINVITEの前にアリスに送信されます。最後に、ボブはアリスと電話を切り、キャロルとの通話を再開します。コンサルトコールのダイアログ通知は使用されないため、表示されません。
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.
ボブがアリスと相談している間にキャロルが電話を切った場合、ボブはアリスとの通話のためにキャロルで使用された外観番号を再利用するかどうかを決定できます。そうでない場合、ボブはキャロルとのダイアログの終了を公開し、外観エージェントは外観を再割り当てします。外観を維持したい場合、ボブはキャロルとのダイアログの終了を公開し、アリスとのダイアログを使用して外観を公開します。これにより、ボブはアリスとのダイアログが終了したことを報告するまで出現番号を保持します。
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].
[RFC7088]で説明されているように、保留音サービスを実装するためにボブがアリスの代わりに保留音サーバーを呼び出した場合、コールフローは同様になることに注意してください。
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 ===================>|
| | | | |
Figure 9. Consultation Hold with Appearances Example
図9.外観のある相談保留の例
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: ...
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：...
<?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>
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].
このコールフローでは、ボブが応答したコールにアリスが参加するか、「ブリッジ」されます。 Joinヘッダーフィールドは、このブリッジを要求するためにAliceによって使用されます。ボブがメディアミキシングをサポートしていなかった場合、ボブは[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<| |
| | | | |
| |>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
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: ...
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：...
<?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>
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
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.
BobはPUBLISHで外観を予約し、INVITEをCarolに送信した後、到達できなくなります。外観エージェントへのパブリケーションの更新に失敗すると、外観エージェントはダイアログが終了したことを宣言し、NOTIFY F14およびF16を使用して外観を解放します。 NOTFYをボブに再送信した後（メッセージ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 |
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.
ボブとアリスは両方とも、同時にパブリッシュすることで外観2を予約しようとします。 Appearance Agentは、200 OKを送信してBobに外観を割り当て、400（Bad Request）応答を送信してAliceに拒否します。 NOTIFY F5の後、アリスはボブがアピアランス2を使用していることを学習します。アリスはパブリッシングによってアピアランス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<| | | |
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 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.
このシナリオでは、外観エージェントは、ボブを介さない限り、ボブのダイアログ状態情報を知る方法がありません。これは、Appearance AgentがB2BUAの一部ではないか、またはBobがリモートで登録している可能性があります。 Bobが登録すると、Appearance Agentはレジストラから登録イベントパッケージ通知を受け取ります。アピアランスエージェントは、SUBSCRIBEのEvent：dialogを使用して、ボブのダイアログイベント状態にサブスクライブします。ボブのダイアログの状態が変化するたびに、ボブのUAはNOTIFYをアピアランスエージェントに送信し、アピアランスエージェントはグループ内の他の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 ------------------------------->|
| | | | |
| | | |<----- 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. UAへのAppearance Agentサブスクリプションの例
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.
このシナリオでは、ボブは図1または図2のコールフローを使用して作成されたキャロルとの確立されたダイアログを持っています。ボブはキャロルを保留にします。アリスはこの通知を受け取り、これをアリスのUIに表示します。アリスはコールをピックアップしようとしますが、ピックアップが完了する前にキャロルが電話を切ります。アリスは、PUBLISH F48を使用して集荷をキャンセルします。失敗した結合のコールフローはほとんど同じであることに注意してください。
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 ->| |
| | | |>F52 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F53<|
Figure 14. Appearance Pickup Race Condition Failure Example
図14.外観ピックアップの競合状態の失敗例
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: ...
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：...
<?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.
アリスは、アピアランス2を着信コールに割り当てると同時にアピアランス2を取得しようとします。アピアランスエージェントは、400（不正な要求）をアリスに送信することにより、競合を解決します。 NOTIFY F6の後で、アリスは着信コールが外観2を使用していることを学習します。アリスは外観3に再公開され、受け入れられます。この例では、外観エージェントからのNOTIFYの前に受信されたINVITEを示しています。
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.
機密性を提供するために、ダイアログ状態情報とダイアログ識別子を提供するNOTIFYまたはPUBLISHメッセージ本文は、[RFC3261]で説明されているS / MIMEなどの標準メカニズムを使用してエンドツーエンドで暗号化できます。または、ホップバイホップベースではありますが、TLSを介してNOTIFYおよびPUBLISHリクエストを送信すると、機密性も提供されます。 UAとAppearance Agentの間のすべてのSUBSCRIBEとPUBLISHは認証される必要があります。適切な認証と機密性がなければ、サードパーティは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.
この機能は、ReplacesやJoinなどの標準のSIPコール制御プリミティブに依存しています。共有外観グループのメンバーのみがこれらのメカニズムを使用できるように、それらの使用に関する適切なアクセス制御を使用する必要があります。 ReplacesまたはJoinヘッダーフィールドを持つすべてのINVITEは、ダイアログの交換または参加を要求するピアが標準のSIPメカニズム（ダイジェストやS / MIMEなど）を使用して適切に認証され、交換を要求する権限がある場合にのみ受け入れられる必要があります。そうしないと、第三者が共有の外観グループ内の既存のダイアログを混乱させたりハイジャックしたりする可能性があります。
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は、INVITEを送信する前に、出現の確認された発作を待たないでください。確認を待つと、偶発的に緊急コールを遅延またはブロックする可能性があります。その性質上、可能な限り迅速に配置する必要があります。代わりに、PUBLISHトランザクションのステータスに関係なく、緊急コールを続行する必要があります。
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イベントヘッダーフィールドパラメーター「共有」、SIP Alert-Infoヘッダーフィールドパラメーター「外観」、および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]で定義されている「Header Field Parameters and Parameter Values」レジストリのEventヘッダーフィールドに「共有」ヘッダーフィールドパラメーターを定義しています。
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]で定義されている「Header Field Parameters and Parameter Values」レジストリのAlert-Infoヘッダーの「appearance」パラメータを定義しています。
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.
うり： うｒん：いえｔｆ：ぱらｍｓ：ｘｍｌ：んｓ：さーぢあぉｇーいんふぉ。
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
This section registers an XML schema per the procedures in [RFC3688].
このセクションでは、[RFC3688]の手順に従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schesa:sa-dialog-info.
うり： うｒん：いえｔｆ：ぱらｍｓ：ｘｍｌ：ｓちぇさ：さーぢあぉｇーいんふぉ。
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：Session Initiation Protocol」 、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。、「The Session Initiation Protocol（SIP）Refer Method」、RFC 3515、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。、「The IETF XML Registry」、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、「Indicating User Agent Capabilities in the Session Initiation Protocol（SIP）」、RFC 3840、2004年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、「The Session Initiation Protocol（SIP） "Replaces" Header」、RFC 3891、2004年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。、「Session State Initiation Protocol（SIP）Extension for Event State Publication」、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、「The Session Initiation Protocol（SIP） "Join" Header」、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）のインターネット割り当て番号機関（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）のINVITEで開始されるダイアログイベントパッケージ」、RFC 4235、2005年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 6665、2012年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。、Jesske、R.、Johnston、A.、Worley、D。、およびP. Kyzivat、「Session Initiation Protocol（SIP）のAlert-Infoヘッダーフィールドの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。、「A Session Initiation Protocol（SIP）Event Package for Registrations」、RFC 3680、2004年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、「Session Initiation Protocol（SIP）Call Control-Conferencing for User Agents」、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]ジョンストン、A。、スパークス、R。、カニンガム、C。、ドノバン、S。、およびK.サマーズ、「Session Initiation Protocol Service Examples」、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。、「Session Initiation Protocol Service Example-Music on Hold」、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.
XMLスキーマを支援してくれたChris Boultonに感謝します。
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 SystemsのKent Fritz、John Weald、およびSunil Veluvali。 Citel TechnologiesのSteve TowlsonとMichael Procter。 Polycom、Inc.のRob HarderおよびHong Chen。シーメンスコミュニケーションズのジョンエルウェルとJDスミス。 PingtelのDale R. Worley。およびYahoo、Inc.のGraeme Dollar
Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell, Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their comments.
また、コメントを提供してくれたGeoff Devine、Paul Kyzivat、Jerry Yin、John Elwell、Dan York、Spenser Dawkins、Martin Dolly、Brett Tateにも感謝します。
Thanks to Carolyn Beeton, Francois Audet, Andy Hutton, Tim Ross, Raji Chinnappa, and Harsh Mendiratta for their detailed review of the document.
ドキュメントの詳細なレビューを提供してくれたCarolyn Beeton、Francois Audet、Andy Hutton、Tim Ross、Raji Chinnappa、Harsh Mendirattaに感謝します。
Authors' Addresses
著者のアドレス
Alan Johnston (editor) Avaya St. Louis, MO United States
あぁん じょｈんｓとん （えぢとｒ） あゔぁや Ｓｔ。 ぉういｓ、 も うにてｄ Ｓたてｓ
EMail: alan.b.johnston@gmail.com
Mohsen Soroushnejad (editor) Sylantro Systems Corp.
Mohsen Soroushnejad（編集者）Sylantro Systems Corp.
EMail: msoroush@gmail.com Venkatesh Venkataramanan Sylantro Systems Corp.
メール：msoroush@gmail.com Venkatesh Venkataramanan Sylantro Systems Corp.
EMail: vvenkatar@gmail.com