[要約] RFC 5850は、SIP（Session Initiation Protocol）のための通話制御とマルチパーティ利用のフレームワークを提供します。このRFCの目的は、SIPを使用して複数の参加者が関与する通話や会議を効果的に制御するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) R. Mahy
Request for Comments: 5850 Unaffiliated
Category: Informational R. Sparks
ISSN: 2070-1721 Tekelec
J. Rosenberg
jdrosen.net
D. Petrie
SIPez
A. Johnston, Ed.
Avaya
May 2010
A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）のコールコントロールとマルチパーティの使用フレームワーク
Abstract
概要
This document defines a framework and the requirements for call control and multi-party usage of the Session Initiation Protocol (SIP). To enable discussion of multi-party features and applications, we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually set up the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state and session history. This framework also describes other goals that embody the spirit of SIP applications as used on the Internet such as the definition of primitives (not services), invoker and participant oriented primitives, signaling and mixing model independence, and others.
このドキュメントでは、セッション開始プロトコル（SIP）のコールコントロールとマルチパーティ使用の要件を定義します。マルチパーティの機能とアプリケーションの議論を可能にするために、これらの多くに必要なメディア関係を説明するための抽象的なコールモデルを定義します。ここで説明するモデルとアクションは、実際にメディア関係を設定するために選択されたSIPシグナリングおよび/または混合アプローチとは独立しているように特に選択されています。対話操作の側面に加えて、このフレームワークには、会議やセッションの状態やセッションの履歴などの関連情報やイベントを伝えるための要件が含まれています。このフレームワークでは、プリミティブ（サービスではなく）、招待者と参加者志向のプリミティブ、シグナル伝達、モデルの独立などの定義など、インターネットで使用されるSIPアプリケーションの精神を具体化する他の目標についても説明しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5850.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5850で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Motivation and Background . . . . . . . . . . . . . . . . . . 4
2. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Conversation Space Model . . . . . . . . . . . . . . . . . 7
2.2. Relationship between Conversation Space, SIP Dialogs,
and SIP Sessions . . . . . . . . . . . . . . . . . . . . . 8
2.3. Signaling Models . . . . . . . . . . . . . . . . . . . . . 9
2.4. Mixing Models . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. Tightly Coupled . . . . . . . . . . . . . . . . . . . 11
2.4.2. Loosely Coupled . . . . . . . . . . . . . . . . . . . 12
2.5. Conveying Information and Events . . . . . . . . . . . . . 13
2.6. Componentization and Decomposition . . . . . . . . . . . . 15
2.6.1. Media Intermediaries . . . . . . . . . . . . . . . . . 15
2.6.2. Text-to-Speech and Automatic Speech Recognition . . . 17
2.6.3. VoiceXML . . . . . . . . . . . . . . . . . . . . . . . 17
2.7. Use of URIs . . . . . . . . . . . . . . . . . . . . . . . 18
2.7.1. Naming Users in SIP . . . . . . . . . . . . . . . . . 19
2.7.2. Naming Services with SIP URIs . . . . . . . . . . . . 20
2.8. Invoker Independence . . . . . . . . . . . . . . . . . . . 22
2.9. Billing Issues . . . . . . . . . . . . . . . . . . . . . . 23
3. Catalog of Call Control Actions and Sample Features . . . . . 23
3.1. Remote Call Control Actions on Early Dialogs . . . . . . . 24
3.1.1. Remote Answer . . . . . . . . . . . . . . . . . . . . 24
3.1.2. Remote Forward or Put . . . . . . . . . . . . . . . . 24
3.1.3. Remote Busy or Error Out . . . . . . . . . . . . . . . 24
3.2. Remote Call Control Actions on Single Dialogs . . . . . . 24
3.2.1. Remote Dial . . . . . . . . . . . . . . . . . . . . . 24
3.2.2. Remote On and Off Hold . . . . . . . . . . . . . . . . 25
3.2.3. Remote Hangup . . . . . . . . . . . . . . . . . . . . 25
3.3. Call Control Actions on Multiple Dialogs . . . . . . . . . 25
3.3.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2. Take . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3. Add . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.4. Local Join . . . . . . . . . . . . . . . . . . . . . . 28
3.3.5. Insert . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.6. Split . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.7. Near-Fork . . . . . . . . . . . . . . . . . . . . . . 29
3.3.8. Far-Fork . . . . . . . . . . . . . . . . . . . . . . . 29
4. Security Considerations . . . . . . . . . . . . . . . . . . . 30
Appendix A. Example Features . . . . . . . . . . . . . . . . . 32
Appendix A.1. Attended Transfer . . . . . . . . . . . . . . . . . 32
Appendix A.2. Auto Answer . . . . . . . . . . . . . . . . . . . . 32
Appendix A.3. Automatic Callback . . . . . . . . . . . . . . . . 32
Appendix A.4. Barge-In . . . . . . . . . . . . . . . . . . . . . 32
Appendix A.5. Blind Transfer . . . . . . . . . . . . . . . . . . 32
Appendix A.6. Call Forwarding . . . . . . . . . . . . . . . . . . 33
Appendix A.7. Call Monitoring . . . . . . . . . . . . . . . . . . 33
Appendix A.8. Call Park . . . . . . . . . . . . . . . . . . . . . 33
Appendix A.9. Call Pickup . . . . . . . . . . . . . . . . . . . . 33
Appendix A.10. Call Return . . . . . . . . . . . . . . . . . . . . 34
Appendix A.11. Call Waiting . . . . . . . . . . . . . . . . . . . 34
Appendix A.12. Click-to-Dial . . . . . . . . . . . . . . . . . . . 34
Appendix A.13. Conference Call . . . . . . . . . . . . . . . . . . 34
Appendix A.14. Consultative Transfer . . . . . . . . . . . . . . . 34
Appendix A.15. Distinctive Ring . . . . . . . . . . . . . . . . . 35
Appendix A.16. Do Not Disturb . . . . . . . . . . . . . . . . . . 35
Appendix A.17. Find-Me . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A.18. Hotline . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A.19. IM Conference Alerts . . . . . . . . . . . . . . . 35
Appendix A.20. Inbound Call Screening . . . . . . . . . . . . . . 35
Appendix A.21. Intercom . . . . . . . . . . . . . . . . . . . . . 36
Appendix A.22. Message Waiting . . . . . . . . . . . . . . . . . . 36
Appendix A.23. Music on Hold . . . . . . . . . . . . . . . . . . . 36
Appendix A.24. Outbound Call Screening . . . . . . . . . . . . . . 36
Appendix A.25. Pre-Paid Calling . . . . . . . . . . . . . . . . . 37
Appendix A.26. Presence-Enabled Conferencing . . . . . . . . . . . 37
Appendix A.27. Single Line Extension/Multiple Line Appearance . . 37
Appendix A.28. Speakerphone Paging . . . . . . . . . . . . . . . . 38
Appendix A.29. Speed Dial . . . . . . . . . . . . . . . . . . . . 38
Appendix A.30. Voice Message Screening . . . . . . . . . . . . . . 38
Appendix A.31. Voice Portal . . . . . . . . . . . . . . . . . . . 39
Appendix A.32. Voicemail . . . . . . . . . . . . . . . . . . . . . 40
Appendix A.33. Whispered Call Waiting . . . . . . . . . . . . . . 40
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 40
5. Informative References . . . . . . . . . . . . . . . . . . . . 40
The Session Initiation Protocol (SIP) [RFC3261] was defined for the initiation, maintenance, and termination of sessions or calls between one or more users. However, despite its origins as a large-scale multi-party conferencing protocol, SIP is used today primarily for point-to-point calls. This two-party configuration is the focus of the SIP specification and most of its extensions.
セッション開始プロトコル（SIP）[RFC3261]は、1人以上のユーザー間のセッションまたはコールの開始、メンテナンス、および終了のために定義されました。ただし、大規模なマルチパーティ会議プロトコルとしての起源にもかかわらず、SIPは主にポイントツーポイントコールに使用されています。この2パーティの構成は、SIP仕様とその拡張のほとんどの焦点です。
This document defines a framework and the requirements for call control and multi-party usage of SIP. Most multi-party operations manipulate SIP dialogs (also known as call legs) or SIP conference media policy to cause participants in a conversation to perceive specific media relationships. In other protocols that deal with the concept of calls, this manipulation is known as call control. In addition to its dialog or policy manipulation aspect, call control also includes communicating information and events related to manipulating calls, including information and events dealing with session state and history, conference state, user state, and even message state.
このドキュメントでは、SIPのコールコントロールとマルチパーティ使用法のフレームワークと要件を定義します。ほとんどのマルチパーティオペレーションは、SIPダイアログ（コール脚とも呼ばれる）またはSIP会議メディアポリシーを操作して、会話の参加者に特定のメディア関係を認識します。呼び出しの概念を扱う他のプロトコルでは、この操作はコールコントロールとして知られています。対話またはポリシーの操作の側面に加えて、コールコントロールには、セッション状態と履歴、会議状態、ユーザー状態、さらにはメッセージ状態を扱う情報やイベントなど、コールの操作に関連する情報とイベントの伝達も含まれます。
Based on input from the SIP community, the authors compiled the following set of goals for SIP call control and multi-party applications:
SIPコミュニティからの入力に基づいて、著者は、SIPコールコントロールとマルチパーティアプリケーションの次の目標セットをまとめました。
o Define primitives, not services. Allow for a handful of robust yet simple mechanisms that can be combined to deliver features and services. Throughout this document, we refer to these simple mechanisms as "primitives". Primitives should be sufficiently robust so that when they are combined with each other, they can be used to build lots of services. However, the goal is not to define a provably complete set of primitives. Note that while the IETF will NOT standardize behavior or services, it may define example services for informational purposes, as in service examples [RFC5359].
o サービスではなくプリミティブを定義します。機能とサービスを提供するために組み合わせることができる、堅牢でありながらシンプルなメカニズムを一握りにしてください。このドキュメント全体で、これらの単純なメカニズムを「プリミティブ」と呼びます。プリミティブは、互いに組み合わされると、多くのサービスを構築するために使用できるように、十分に堅牢である必要があります。ただし、目標は、実証的に完全なプリミティブセットを定義することではありません。IETFは行動やサービスを標準化するものではありませんが、サービスの例[RFC5359]のように、情報目的のためのサンプルサービスを定義する可能性があることに注意してください。
o Be participant oriented. The primitives should be designed to provide services that are oriented around the experience of the participants. The authors observe that end users of features and services usually don't care how a media relationship is set up.
o 参加者になります。プリミティブは、参加者の経験を中心に向けられたサービスを提供するように設計する必要があります。著者は、機能とサービスのエンドユーザーが通常、メディア関係がどのように設定されるかを気にしないことを観察しています。
Their ultimate experience is only based on the resulting media and other externally visible characteristics.
彼らの究極の経験は、結果として生じるメディアやその他の外部的に目に見える特性にのみ基づいています。
o Be signaling model independent. Support both a central-control and a peer-to-peer feature invocation model (and combinations of the two). Baseline SIP already supports a centralized control model described in 3pcc (third party call control) [RFC3725], and the SIP community has expressed a great deal of interest in peer-to-peer or distributed call control using primitives such as those defined in REFER [RFC3515], Replaces [RFC3891], and Join [RFC3911].
o シグナリングモデルに独立してください。中央制御とピアツーピア機能の呼び出しモデル（および2つの組み合わせ）の両方をサポートします。ベースラインSIPは、3PCC（サードパーティコールコントロール）[RFC3725]に記載されている集中制御モデルを既にサポートしており、SIPコミュニティは、紹介で定義されているようなプリミティブを使用して、ピアツーピアまたは分散コールコントロールに大きな関心を表明しています。[RFC3515]、[RFC3891]を置き換え、[RFC3911]に結合します。
o Be mixing model independent. The bulk of interesting multi-party applications involve mixing or combining media from multiple participants. This mixing can be performed by one or more of the participants or by a centralized mixing resource. The experience of the participants should not depend on the mixing model used. While most examples in this document refer to audio mixing, the framework applies to any media type. In this context, a "mixer" refers to combining media of the same type in an appropriate, media-specific way. This is consistent with the model described in the SIP conferencing framework.
o モデルを独立して混合します。興味深いマルチパーティアプリケーションの大部分には、複数の参加者のメディアを混合または組み合わせることが含まれます。この混合は、1人以上の参加者または集中混合リソースによって実行できます。参加者の経験は、使用される混合モデルに依存してはなりません。このドキュメントのほとんどの例はオーディオミキシングを参照していますが、フレームワークは任意のメディアタイプに適用されます。これに関連して、「ミキサー」とは、同じタイプのメディアを適切なメディア固有の方法で組み合わせることを指します。これは、SIP会議のフレームワークで説明されているモデルと一致しています。
o Be invoker oriented. Only the user who invokes a feature or a service needs to know exactly which service is invoked or why. This is good because it allows new services to be created without requiring new primitives from all of the participants; and it allows for much simpler feature authorization policies, for example, when participation spans organizational boundaries. As discussed in Section 2.7, this also avoids exponential state explosion when combining features. The invoker only has to manage a user interface or application programming interface (API) to prevent local feature interactions. All the other participants simply need to manage the feature interactions of a much smaller number of primitives.
o 招待者志向になります。機能またはサービスを呼び出すユーザーのみが、どのサービスが呼び出されたのか、またはその理由を正確に知る必要があります。これは、すべての参加者からの新しいプリミティブを必要とせずに新しいサービスを作成できるため、これは良いことです。また、たとえば、参加が組織の境界に及ぶ場合、はるかに単純な機能認証ポリシーが可能になります。セクション2.7で説明したように、これは機能を組み合わせるときの指数関数的な状態爆発も回避します。招待者は、ローカル機能のインタラクションを防ぐために、ユーザーインターフェイスまたはアプリケーションプログラミングインターフェイス（API）を管理するだけです。他のすべての参加者は、はるかに少ない数のプリミティブの特徴的な相互作用を管理する必要があります。
o Primitives make full use of URIs (uniform resource identifiers). URIs are a very powerful mechanism for describing users and services. They represent a plentiful resource that can be extremely expressive and easily routed, translated, and manipulated -- even across organizational boundaries. URIs can contain special parameters and informational header fields that need only be relevant to the owner of the namespace (domain) of the URI. Just as a user who selects an http: URL need not understand the significance and organization of the web site it references, a user may encounter a SIP URI that translates into an email-style group alias, which plays a pre-recorded message or runs some complex call-handling logic. Note that while this may seem paradoxical to the previous goal, both goals can be satisfied by the same model.
o プリミティブは、URIS（均一なリソース識別子）を完全に使用します。URIは、ユーザーとサービスを説明するための非常に強力なメカニズムです。それらは、非常に表現力豊かで、組織の境界を越えても簡単にルーティング、翻訳、操作できる豊富なリソースを表しています。URIは、URIの名前空間（ドメイン）の所有者にのみ関連する必要がある特別なパラメーターと情報ヘッダーフィールドを含めることができます。HTTP：URLを選択するユーザーが参照するWebサイトの重要性と組織を理解する必要がないように、ユーザーは、事前に録音されたメッセージを再生するか実行する電子メールスタイルのグループエイリアスに変換されるSIP URIに遭遇する可能性があります。複雑なコール処理ロジック。これは以前の目標とは逆説的に見えるかもしれませんが、同じモデルによって両方の目標が満たされる可能性があることに注意してください。
o Make use of SIP header fields and SIP event packages to provide SIP entities with information about their environment. These should include information about the status/handling of dialogs on other user agents (UAs), information about the history of other contacts attempted prior to the current contact, the status of participants, the status of conferences, user presence information, and the status of messages.
o SIPヘッダーフィールドとSIPイベントパッケージを使用して、SIPエンティティに環境に関する情報を提供します。これらには、他のユーザーエージェント（UAS）に関するダイアログのステータス/処理に関する情報、現在の連絡先の前に試みられた他の連絡先の履歴、参加者のステータス、会議のステータス、ユーザーの存在情報、およびステータスを含める必要があります。メッセージの。
o Encourage service decomposition, and design to make use of standard components using well-defined, simple interfaces. Sample components include a SIP mixer, recording service, announcement server, and voice-dialog server. (This is not an exhaustive list).
o 明確でシンプルなインターフェイスを使用して標準コンポーネントを使用するために、サービス分解と設計を奨励します。サンプルコンポーネントには、SIPミキサー、レコーディングサービス、アナウンスサーバー、Voice-Dialogサーバーが含まれます。（これは網羅的なリストではありません）。
o Include authentication, authorization, policy, logging, and accounting mechanisms to allow these primitives to be used safely among mutually untrusted participants. Some of these mechanisms may be used to assist in billing, but no specific billing system will be endorsed.
o 認証、承認、ポリシー、ロギング、および会計メカニズムを含めて、これらのプリミティブを相互に信頼されていない参加者の間で安全に使用できるようにします。これらのメカニズムの一部は、請求を支援するために使用できますが、特定の請求システムは承認されません。
o Permit graceful fallback to baseline SIP. Definitions for new SIP call control extensions/primitives must describe a graceful way to fallback to baseline SIP behavior. Support for one primitive must not imply support for another primitive.
o ベースラインSIPへの優雅なフォールバックを許可します。新しいSIPコールコントロール拡張機能/プリミティブの定義は、ベースラインSIPの動作へのフォールバックの優雅な方法を説明する必要があります。ある原始のサポートは、別の原始のサポートを意味してはなりません。
o Don't reinvent traditional models, such as the model used for the H.450 family of protocols, JTAPI (Java Telephony Application Programming Interface), or the CSTA (Computer-supported telecommunications applications) call model, as these other models do not share the design goals presented in this document.
o H.450ファミリーのプロトコル、JTAPI（Javaテレフォニーアプリケーションプログラミングインターフェイス）、またはCSTA（コンピューターサポートされたテレコミューションアプリケーション）コールモデルに使用されるモデルなど、従来のモデルを再発明しないでください。これらのモデルは共有していないためこのドキュメントに示されている設計目標。
Note that the flexibility in this model does have some disadvantages in terms of interoperability. It is possible to build a call control feature in SIP using different combinations of primitives. For a discussion of the issues associated with this, see [BLISS-PROBLEM].
このモデルの柔軟性には、相互運用性の観点からいくつかの欠点があることに注意してください。プリミティブのさまざまな組み合わせを使用して、SIPでコールコントロール機能を構築することができます。これに関連する問題の議論については、[Bliss-Problem]を参照してください。
This section introduces a number of key concepts that will be used to describe and explain various call control operations and services in the remainder of this document. This includes the conversation space model, signaling and mixing models, common components, and the use of URIs.
このセクションでは、このドキュメントの残りの部分でさまざまなコールコントロール操作とサービスを説明および説明するために使用される多くの重要な概念を紹介します。これには、会話空間モデル、シグナリングモデルとミキシングモデル、一般的なコンポーネント、およびURIの使用が含まれます。
This document introduces the concept of an abstract "conversation space" as a set of participants who believe they are all communicating among one another. Each conversation space contains one or more participants.
このドキュメントでは、抽象的な「会話スペース」の概念を、すべてがお互いにコミュニケーションをとっていると信じている参加者のセットとして紹介します。各会話スペースには、1人以上の参加者が含まれています。
Participants are SIP UAs that send original media to or terminate and receive media from other members of the conversation space. Logically, every participant in the conversation space has access to all the media generated in that space (this is strictly true if all participants share a common media type). A SIP UA that does not contribute or consume any media is NOT a participant, nor is a UA that merely forwards, transcodes, mixes, or selects media originating elsewhere in the conversation space.
参加者は、会話スペースの他のメンバーからオリジナルのメディアを送信または終了してメディアを受け取るSIP UASです。論理的には、会話スペースのすべての参加者は、そのスペースで生成されたすべてのメディアにアクセスできます（すべての参加者が共通のメディアタイプを共有する場合、これは厳密に真実です）。メディアに貢献したり消費したりしないSIP UAは、参加者ではなく、会話スペースの他の場所で発生するメディアを転送、トランスコード、ミックス、または選択するだけでもありません。
Note that a conversation space consists of zero or more SIP calls or SIP conferences. A conversation space is similar to the definition of a "call" in some other call models.
会話スペースは、ゼロ以上のSIPコールまたはSIP会議で構成されていることに注意してください。会話スペースは、他のいくつかの呼び出しモデルの「呼び出し」の定義に似ています。
Participants may represent human users or non-human users (referred to as robots or automatons in this document). Some participants may be hidden within a conversation space. Some examples of hidden participants include: robots that generate tones, images, or announcements during a conference to announce users arriving and departing, a human call center supervisor monitoring a conversation between a trainee and a customer, and robots that record media for training or archival purposes.
参加者は、人間のユーザーまたは人間以外のユーザー（このドキュメントのロボットまたはオートマトンと呼ばれる）を代表する場合があります。一部の参加者は、会話の分野内に隠されている場合があります。隠された参加者の例には、会議中にトーン、画像、または発表を生成するロボットが含まれます。ユーザーが到着し出発することを発表し、研修生と顧客の間の会話を監視する人間のコールセンターの監督、トレーニングやアーカイブのためにメディアを記録するロボット目的。
Participants may also be active or passive. Active participants are expected to be intelligent enough to leave a conversation space when they no longer desire to participate. (An attentive human participant is obviously active.) Some robotic participants (such as a voice-messaging system, an instant-messaging agent, or a voice-dialog system) may be active participants if they can leave the conversation space when there is no human interaction. Other robots (for example, our tone-generating robot from the previous example) are passive participants. A human participant "on hold" is passive.
参加者もアクティブまたはパッシブである場合があります。アクティブな参加者は、参加を望んでいないときに会話のスペースを残すのに十分な知性があると予想されます。（注意深い人間の参加者は明らかにアクティブです。）一部のロボット参加者（音声メッセージシステム、インスタントメッシングエージェント、または音声ダイアログシステムなど）は、会話スペースを離れることができればアクティブな参加者になる可能性があります。人的交流。他のロボット（たとえば、前の例からトーン生成ロボット）は受動的な参加者です。「保留中」の人間の参加者は受動的です。
An example diagram of a conversation space can be shown as a "bubble" or ovals, or as a "set" in curly or square bracket notation. Each set, oval, or bubble represents a conversation space. Hidden participants are shown in lowercase letters. Examples are given in Figure 1.
会話空間の例の図は、「バブル」または楕円形として、または巻き毛または四角いブラケット表記の「セット」として表示できます。各セット、楕円形、またはバブルは会話空間を表します。隠された参加者は小文字で表示されます。例を図1に示します。
Note that while the term "conversation" usually applies to oral exchange of information, we apply the conversation space model to any media exchange between participants.
「会話」という用語は通常、情報の口頭交換に適用されますが、参加者間のメディア交換に会話空間モデルを適用することに注意してください。
{ A , B } [ A , b, C, D ]
{a、b} [a、b、c、d]
.-. .---.
/ \ / \
/ A \ / A b \
( ) ( )
\ B / \ C D /
\ / \ /
'-' '---'
Figure 1. Conversation Spaces
図1.会話スペース
In [RFC3261], a call is "an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation". The concept of a conversation space is needed because the SIP definition of call is not sufficiently precise for the purpose of describing the user experience of multi-party features.
[RFC3261]では、呼び出しは「ピア間のコミュニケーションを指す非公式の用語であり、一般的にマルチメディア会話の目的のために設定されています」。通話のSIP定義は、マルチパーティ機能のユーザーエクスペリエンスを説明する目的で十分に正確ではないため、会話スペースの概念が必要です。
Do any other definitions convey the correct meaning? SIP and SDP (Session Description Protocol) [RFC4566] both define a conference as "a multimedia session identified by a common session description". A session is defined as "a set of multimedia senders and receivers and the data streams flowing from senders to receivers". The definition of "call" in some call models is more similar to our definition of a conversation space.
他の定義は正しい意味を伝えていますか？SIPとSDP（セッション説明プロトコル）[RFC4566]はどちらも、会議を「共通のセッションの説明で識別するマルチメディアセッション」と定義しています。セッションは、「一連のマルチメディア送信者とレシーバー、および送信者からレシーバーへの流れるデータストリーム」として定義されます。一部のコールモデルの「呼び出し」の定義は、会話空間の定義により似ています。
Some examples of the relationship between conversation spaces, SIP dialogs, and SIP sessions are listed below. In each example, a human user will perceive that there is a single call.
会話スペース、SIPダイアログ、SIPセッションの関係のいくつかの例を以下に示します。それぞれの例では、人間のユーザーが1回の呼び出しがあることを知覚します。
o A simple two-party call is a single conversation space, a single session, and a single dialog.
o 単純な2パーティの呼び出しは、単一の会話スペース、単一のセッション、および単一のダイアログです。
o A locally mixed three-way call is two sessions and two dialogs. It is also a single conversation space.
o ローカルに混合された3者間コールは、2つのセッションと2つのダイアログです。また、単一の会話スペースでもあります。
o A simple dial-in audio conference is a single conversation space, but is represented by as many dialogs and sessions as there are human participants.
o シンプルなダイヤルインオーディオカンファレンスは単一の会話スペースですが、人間の参加者と同じくらい多くのダイアログとセッションで表されます。
o A multicast conference is a single conversation space, a single session, and as many dialogs as participants.
o マルチキャスト会議は、単一の会話スペース、単一のセッション、および参加者と同じくらい多くのダイアログです。
Obviously, to make changes to a conversation space, you must be able to use SIP signaling to cause these changes. Specifically, there must be a way to manipulate SIP dialogs (call legs) to move participants into and out of conversation spaces. Although this is not as obvious, there also must be a way to manipulate SIP dialogs to include non-participant UAs that are otherwise involved in a conversation space (e.g., back-to-back user agents or B2BUAs, third party call control (3pcc) controllers, mixers, transcoders, translators, or relays).
明らかに、会話スペースに変更を加えるには、SIPシグナリングを使用してこれらの変更を引き起こす必要があります。具体的には、参加者を会話スペースに出入りさせるために、SIPダイアログ（コール脚）を操作する方法が必要です。これはそれほど明白ではありませんが、SIPダイアログを操作して、会話分野に関与する非参加者UASを含める方法もある必要があります（例：連続したユーザーエージェントやB2BUA、サードパーティのコールコントロール（3PCC）コントローラー、ミキサー、トランスコダー、翻訳者、またはリレー）。
Implementations may setup the media relationships described in the conversation space model using a centralized control model. One common way to implement this using SIP is known as third party call control (3pcc) and is described in 3pcc [RFC3725]. The 3pcc approach relies on only the following three primitive operations:
実装は、集中制御モデルを使用して、会話空間モデルで説明されているメディア関係をセットアップする場合があります。SIPを使用してこれを実装する1つの一般的な方法は、サードパーティコールコントロール（3PCC）として知られており、3PCC [RFC3725]で説明されています。3PCCアプローチは、次の3つの原始操作のみに依存しています。
o Create a new dialog (INVITE)
o 新しいダイアログを作成する（招待）
o Modify a dialog (reINVITE)
o ダイアログ（Reinvite）を変更する
o Destroy a dialog (BYE)
o ダイアログを破壊する（さようなら）
The main advantage of the 3pcc approach is that it only requires very basic SIP support from end systems to support call control features. As such, third party call control is a natural way to handle protocol conversion and mid-call features. It also has the advantage and disadvantage that new features can/must be implemented in one place only (the controller), and it neither requires enhanced client functionality nor takes advantage of it.
3PCCアプローチの主な利点は、コールコントロール機能をサポートするために、エンドシステムからの非常に基本的なSIPサポートのみが必要であることです。そのため、サードパーティのコールコントロールは、プロトコル変換とミッドコール機能を処理するための自然な方法です。また、新しい機能を1つの場所（コントローラー）で実装できる/必要があるという利点と不利な点もあり、クライアント機能を強化する必要もそれを利用することもできません。
In addition, a peer-to-peer approach is discussed at length in this document. The primary drawback of the peer-to-peer model is additional complexity in the end system and authentication and management models. The benefits of the peer-to-peer model include:
さらに、このドキュメントでは、ピアツーピアアプローチについて詳しく説明します。ピアツーピアモデルの主な欠点は、エンドシステムと認証および管理モデルの追加の複雑さです。ピアツーピアモデルの利点は次のとおりです。
o state remains at the edges,
o 状態は端に残り、
o call signaling need only go through participants involved (there are no additional points of failure), and
o コールシグナリングは、関係する参加者のみを通過する必要があります（障害の追加ポイントはありません）、そして
o peers may take advantage of end-to-end message integrity or encryption
o ピアはエンドツーエンドのメッセージの整合性または暗号化を利用する場合があります
The peer-to-peer approach relies on additional "primitive" operations, some of which are identified here.
ピアツーピアアプローチは、追加の「原始的な」操作に依存しており、その一部はここで特定されています。
o Replace an existing dialog
o 既存のダイアログを置き換えます
o Join a new dialog with an existing dialog
o 既存のダイアログで新しいダイアログに参加します
o Locally perform media forking (multi-unicast)
o メディアフォーキング（マルチユニカスト）をローカルに実行する
o Ask another user agent (UA) to send a request on your behalf
o 別のユーザーエージェント（UA）にお客様に代わってリクエストを送信するように依頼します
The peer-to-peer approach also only results in a single SIP dialog, directly between the two UAs. The 3pcc approach results in two SIP dialogs, between each UA and the controller. As a result, the SIP features and extensions that will be used during the dialog are limited to the those understood by the controller. As a result, in a situation where both the UAs support an advanced SIP feature but the controller does not, the feature will not be able to be used.
ピアツーピアアプローチは、2つのUAの間に直接、単一のSIPダイアログのみをもたらします。3PCCアプローチにより、各UAとコントローラーの間に2つのSIPダイアログが表示されます。その結果、ダイアログ中に使用されるSIP機能と拡張機能は、コントローラーが理解しているものに限定されます。その結果、両方のUASが高度なSIP機能をサポートしているがコントローラーがサポートしていない状況では、機能を使用できません。
Many of the features, primitives, and actions described in this document also require some type of media mixing, combining, or selection as described in the next section.
このドキュメントで説明されている機能、プリミティブ、およびアクションの多くは、次のセクションで説明されているように、何らかのタイプのメディアミキシング、組み合わせ、または選択も必要です。
SIP permits a variety of mixing models, which are discussed here briefly. This topic is discussed more thoroughly in the SIP conferencing framework [RFC4353] and [RFC4579]. SIP supports both tightly coupled and loosely coupled conferencing, although more sophisticated behavior is available in tightly coupled conferences. In a tightly coupled conference, a single SIP user agent (called the focus) has a direct dialog relationship with each participant (and may control non-participant user agents as well). The focus can authoritatively publish information about the character and participants in a conference. In a loosely coupled conference, there are no coordinated signaling relationships among the participants.
SIPでは、さまざまなミキシングモデルを許可します。これらについては、ここで簡単に説明します。このトピックは、SIP会議のフレームワーク[RFC4353]および[RFC4579]でより徹底的に説明されています。SIPは、緊密に結合された会議とゆるく結合された会議の両方をサポートしますが、より洗練された動作は、緊密に結合された会議で利用できます。緊密に結合された会議では、単一のSIPユーザーエージェント（フォーカスと呼ばれる）が各参加者と直接の対話関係を持っています（また、参加者以外のユーザーエージェントも制御する場合があります）。焦点は、会議のキャラクターと参加者に関する情報を権威あるものに公開できます。大まかに結合された会議では、参加者間の調整されたシグナル伝達関係はありません。
For brevity, only the two most popular conferencing models are significantly discussed in this document (local and centralized mixing). Applications of the conversation spaces model to loosely coupled multicast and distributed full unicast mesh conferences are left as an exercise for the reader. Note that a distributed full mesh conference can be used for basic conferences, but does not easily allow for more complex conferencing actions like splitting, merging, and sidebars.
簡潔にするために、このドキュメント（ローカルおよび集中化された混合）で大幅に議論されている2つの最も人気のある会議モデルのみが重要です。ゆるく結合したマルチキャストと分散された完全なユニキャストメッシュ会議への会話スペースモデルのアプリケーションは、読者の演習として残されています。分散型フルメッシュ会議は基本的な会議に使用できるが、分割、マージ、サイドバーなどのより複雑な会議アクションを簡単に許可しないことに注意してください。
Call control features should be designed to allow a mixer (local or centralized) to decide when to reduce a conference back to a two-party call, or drop all the participants (for example, if only two automatons are communicating). The actual heuristics used to release calls are beyond the scope of this document, but may depend on properties in the conversation space, such as the number of active, passive, or hidden participants and the send-only, receive-only, or send-and-receive orientation of various participants.
コールコントロール機能は、ミキサー（ローカルまたは集中型）を許可して、会議を2つのパーティコールに戻すタイミングを決定するか、すべての参加者をドロップするように設計する必要があります（たとえば、2つのオートマトンのみが通信している場合）。通話のリリースに使用される実際のヒューリスティックは、このドキュメントの範囲を超えていますが、アクティブ、パッシブ、または非表示の参加者の数や送信専用、受信のみ、または送信など、会話スペースのプロパティに依存する場合があります。さまざまな参加者のreceiveオリエンテーション。
Tightly coupled conferences utilize a central point for signaling and authentication known as a focus [RFC4353]. The actual media can be centrally mixed or distributed.
緊密に結合された会議は、フォーカスとして知られるシグナリングと認証の中心的なポイントを利用しています[RFC4353]。実際のメディアは、中央に混合または分布することができます。
The first model we call "end system mixing". In this model, user A calls user B, and they have a conversation. At some point later, A decides to conference in user C. To do this, A calls C, using a completely separate SIP call. This call uses a different Call-ID, different tags, etc. There is no call set up directly between B and C. No SIP extension or external signaling is needed. A merely decides to locally join two dialogs.
「エンドシステムミキシング」と呼ばれる最初のモデル。このモデルでは、ユーザーAはユーザーBを呼び出し、会話があります。ある時点で、AはユーザーCで会議を行うことを決定します。これを行うには、Call Call cが完全に独立したSIP呼び出しを使用します。この通話は、異なるコールID、異なるタグなどを使用します。BとCの間に直接セットアップされたコールはありません。SIP拡張または外部シグナルは必要ありません。Aは、2つのダイアログにローカルに参加することを決定するだけです。
B C
\ /
\ /
A
Figure 2. End System Mixing Example
図2.エンドシステムの混合例
In Figure 2, A receives media streams from both B and C, and mixes them. A sends a stream containing A's and C's streams to B, and a stream containing A's and B's streams to C. Basically, user A handles both signaling and media mixing.
図2では、AはBとCの両方からメディアストリームを受信し、それらを混合します。Aは、AとCのストリームをBに含むストリームと、AとBのストリームをCに含むストリームをCに送信します。基本的に、ユーザーAはシグナリングとメディアミキシングの両方を処理します。
In a centralized mixing model, all participants have a pairwise SIP and media relationship with the mixer. Common applications of centralized mixing include ad hoc conferences and scheduled dial-in or dial-out conferences. In Figure 3 below, the mixer M receives and sends media to participants A, B, C, D, and E.
集中混合モデルでは、すべての参加者がペアワイズSIPとミキサーとのメディア関係を持っています。集中混合の一般的なアプリケーションには、アドホック会議とスケジュールされたダイヤルインまたはダイヤルアウト会議が含まれます。以下の図3では、ミキサーMが参加者A、B、C、D、およびEにメディアを受信して送信します。
B C
\ /
\ /
M --- A
/ \
/ \
D E
Figure 3. Centralized Mixing Example
図3.集中混合の例
In this conferencing model, there is a centralized controller, as in the dial-in and dial-out cases. However, the centralized server handles signaling only. The media is still sent directly between participants, using either multicast or multi-unicast. Participants perform their own mixing. Multi-unicast is when a user sends multiple packets (one for each recipient, addressed to that recipient). This is referred to as a "Decentralized Multipoint Conference" in [H.323]. Full mesh media with centralized mixing is another approach.
この会議モデルには、ダイヤルインおよびダイヤルアウトの場合のように、集中コントローラーがあります。ただし、集中サーバーはシグナリングのみを処理します。メディアは、マルチキャストまたはマルチユニカストのいずれかを使用して、参加者間で直接送信されます。参加者は独自のミキシングを実行します。Multi-Unicastは、ユーザーが複数のパケットを送信する場合（各受信者に1つ、その受信者にアドレス指定されます）。これは[H.323]の「分散型マルチポイント会議」と呼ばれます。一元化されたミキシングを備えたフルメッシュメディアは、別のアプローチです。
In these models, there is no point of central control of SIP signaling. As in the "Centralized Signaling, Distributed Media" case above, all endpoints send media to all other endpoints. Consequently, every endpoint mixes their own media from all the other sources and sends their own media to every other participant.
これらのモデルでは、SIPシグナル伝達の中央制御の意味はありません。上記の「集中化されたシグナリング、分散メディア」ケースのように、すべてのエンドポイントは他のすべてのエンドポイントにメディアを送信します。その結果、すべてのエンドポイントは他のすべてのソースから自分のメディアをミックスし、他のすべての参加者に自分のメディアを送信します。
Large-scale multicast conferences were the original motivation for both the Session Description Protocol (SDP) [RFC4566] and SIP. In a large-scale multicast conference, one or more multicast addresses are allocated to the conference. Each participant joins those multicast groups and sends their media to those groups. Signaling is not sent to the multicast groups. The sole purpose of the signaling is to inform participants of which multicast groups to join. Large-scale multicast conferences are usually pre-arranged, with specific start and stop times. However, multicast conferences do not need to be pre-arranged, so long as a mechanism exists to dynamically obtain a multicast address.
大規模なマルチキャスト会議は、セッション説明プロトコル（SDP）[RFC4566]とSIPの両方の元の動機でした。大規模なマルチキャスト会議では、1つ以上のマルチキャストアドレスが会議に割り当てられます。各参加者はこれらのマルチキャストグループに参加し、メディアをそれらのグループに送ります。シグナリングはマルチキャストグループに送信されません。シグナリングの唯一の目的は、参加者に参加するマルチキャストグループを通知することです。通常、大規模なマルチキャスト会議は事前に配置されており、特定の開始時間と停止時間があります。ただし、マルチキャストアドレスを動的に取得するメカニズムが存在する限り、マルチキャスト会議は事前に配置する必要はありません。
In this conferencing model, each participant has both a pairwise media relationship and a pairwise signaling relationship with every other participant (a full mesh). This model requires a mechanism to maintain a consistent view of distributed state across the group. This is a classic, hard problem in computer science. Also, this model does not scale well for large numbers of participants. For <n> participants, the number of media and signaling relationships is approximately n-squared. As a result, this model is not generally available in commercial implementations; to the contrary, it is primarily the topic of research or experimental implementations. Note that this model assumes peer-to-peer signaling.
この会議モデルでは、各参加者は、ペアワイズメディア関係と、他のすべての参加者（フルメッシュ）とのペアワイズシグナリング関係の両方を持っています。このモデルには、グループ全体で分布した状態の一貫したビューを維持するメカニズムが必要です。これは、コンピューターサイエンスの古典的で難しい問題です。また、このモデルは、多数の参加者にとってうまく拡張しません。<n>参加者の場合、メディアとシグナリングの関係の数は約n-squaredです。その結果、このモデルは一般的に商用実装では利用できません。それどころか、それは主に研究または実験的実装のトピックです。このモデルはピアツーピアシグナリングを想定していることに注意してください。
Participants should have access to information about the other participants in a conversation space so that this information can be rendered to a human user or processed by an automaton. Although some of this information may be available from the Request-URI or To, From, Contact, or other SIP header fields, another mechanism of reporting this information is necessary.
参加者は、会話スペースの他の参加者に関する情報にアクセスできるように、この情報を人間のユーザーに提供したり、オートマトンで処理したりできるようにする必要があります。この情報の一部は、Request-uriまたは、、連絡先、またはその他のSIPヘッダーフィールドから利用できる場合がありますが、この情報を報告する別のメカニズムが必要です。
Many applications are driven by knowledge about the progress of calls and conferences. In general, these types of events allow for the construction of distributed applications, where the application requires information on dialog and conference state, but is not necessarily a co-resident with an endpoint user agent or conference server. For example, a focus involved in a conversation space may wish to provide URIs for conference status and/or conference/floor control.
多くのアプリケーションは、通話と会議の進捗に関する知識によって推進されています。一般に、これらのタイプのイベントにより、アプリケーションがダイアログと会議状態に関する情報を必要とする分散アプリケーションの構築が可能になりますが、必ずしもエンドポイントユーザーエージェントまたは会議サーバーとの共同住宅ではありません。たとえば、会話スペースに携わる焦点は、会議のステータスや会議/フロアコントロールにURIを提供したい場合があります。
The SIP Events architecture [RFC3265] defines general mechanisms for subscription to and notification of events within SIP networks. It introduces the notion of a package that is a specific "instantiation" of the events mechanism for a well-defined set of events.
SIPイベントアーキテクチャ[RFC3265]は、SIPネットワーク内のイベントへのサブスクリプションと通知の一般的なメカニズムを定義します。明確に定義された一連のイベントセットのイベントメカニズムの特定の「インスタンス化」であるパッケージの概念を紹介します。
Event packages are needed to provide the status of a user's dialogs, the status of conferences and their participants, user-presence information, the status of registrations, and the status of a user's messages. While this is not an exhaustive list, these are sufficient to enable the sample features described in this document.
イベントパッケージは、ユーザーのダイアログのステータス、会議のステータスと参加者、ユーザープレゼンス情報、登録のステータス、およびユーザーのメッセージのステータスを提供するために必要です。これは網羅的なリストではありませんが、これらはこのドキュメントで説明されているサンプル機能を有効にするのに十分です。
The conference event package [RFC4575] allows users to subscribe to information about an entire tightly coupled SIP conference. Notifications convey information about the participants such as the SIP URI identifying each user, their status in the space (active, declined, departed), URIs to invoke other features (such as sidebar conversations), links to other relevant information (such as floor-control policies), and if floor-control policies are in place, the user's floor-control status. For conversation spaces created from cascaded conferences, conversation state can be gathered from relevant foci and merged into a cohesive set of state.
会議イベントパッケージ[RFC4575]を使用すると、ユーザーは厳密に結合したSIP会議全体に関する情報を購読できます。通知は、各ユーザーを識別するSIP URI、スペース内のステータス（アクティブ、拒否、出発）、他の機能（サイドバー会話など）を呼び出すためのURIS、他の関連情報（フロアなど）へのリンクなどの参加者に関する情報を伝えます。制御ポリシー）、およびフロアコントロールポリシーが整っている場合、ユーザーのフロアコントロールステータス。カスケードされた会議から作成された会話スペースの場合、会話状態は関連する焦点から収集し、まとまりのある状態に統合できます。
The dialog package [RFC4235] provides information about all the dialogs the target user is maintaining, in which conversations the user is participating, and how these are correlated. Likewise, the registration package [RFC3680] provides notifications when contacts have changed for a specific address-of-record (AOR). The combination of these allows a user agent to learn about all conversations occurring for the entire registered contact set for an address-of-record.
ダイアログパッケージ[RFC4235]は、ターゲットユーザーが維持しているすべてのダイアログ、ユーザーが参加している会話、およびこれらがどのように相関するかについての情報を提供します。同様に、登録パッケージ[RFC3680]は、特定の録音アドレス（AOR）の連絡先が変更された場合に通知を提供します。これらの組み合わせにより、ユーザーエージェントは、登録された連絡先セット全体で発生するすべての会話について学習できます。
Note that user presence in SIP [RFC3856] has a close relationship with these latter two event packages. It is fundamental to the presence model that the information used to obtain user presence is constructed from any number of different input sources. Examples of other such sources include calendaring information and uploads of presence documents. These two packages can be considered another mechanism that allows a presence agent to determine the presence state of the user. Specifically, a user presence server can act as a subscriber for the dialog and registration packages to obtain additional information that can be used to construct a presence document.
SIP [RFC3856]のユーザーの存在は、これらの後者の2つのイベントパッケージと密接な関係があることに注意してください。ユーザーの存在を取得するために使用される情報が、任意の数の異なる入力ソースから構築されることは、存在モデルの基本です。他のそのようなソースの例には、カレンダー情報や存在書類のアップロードが含まれます。これらの2つのパッケージは、存在エージェントがユーザーの存在状態を決定できる別のメカニズムと見なすことができます。具体的には、ユーザープレゼンスサーバーは、ダイアログパッケージと登録パッケージのサブスクライバーとして機能し、プレゼンスドキュメントの構築に使用できる追加情報を取得できます。
The multi-party architecture may also need to provide a mechanism to get information about the status/handling of a dialog (for example, information about the history of other contacts attempted prior to the current contact). Finally, the architecture should provide ample opportunities to present informational URIs that relate to calls, conversations, or dialogs in some way. For example, consider the SIP Call-Info header or Contact header fields returned in a 300-class response. Frequently, additional information about a call or dialog can be fetched via non-SIP URIs. For example, consider a web page for package tracking when calling a delivery company or a web page with related documentation when joining a dial-in conference. The use of URIs in the multi-party framework is discussed in more detail in Section 3.7.
マルチパーティアーキテクチャは、ダイアログのステータス/処理に関する情報を取得するメカニズムを提供する必要がある場合があります（たとえば、現在の連絡先の前に試みられた他の連絡先の履歴に関する情報）。最後に、アーキテクチャは、何らかの方法で電話、会話、または対話に関連する情報提供を提示する十分な機会を提供する必要があります。たとえば、300クラスの応答で返されたSIPコールINFOヘッダーまたは連絡先ヘッダーフィールドを検討してください。多くの場合、通話またはダイアログに関する追加情報は、非SIP URIを介して取得できます。たとえば、配達会社に電話するときはパッケージ追跡のWebページまたはダイヤルイン会議に参加する際に関連するドキュメントを備えたWebページを検討してください。マルチパーティフレームワークでのURIの使用については、セクション3.7で詳しく説明します。
Finally, the interaction of SIP with stimulus-signaling-based applications, which allow a user agent to interact with an application without knowledge of the semantics of that application, is discussed in the SIP application interaction framework [RFC5629]. Stimulus signaling can occur with a user interface running locally with the client, or with a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms, from clicking on hyperlinks, to pressing buttons, to traditional Dual-Tone Multi Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in that framework.
最後に、SIPと刺激シグナルベースのアプリケーションとの相互作用は、ユーザーエージェントがそのアプリケーションのセマンティクスの知識なしにアプリケーションと対話できるようにすることで、SIPアプリケーションインタラクションフレームワーク[RFC5629]で説明されています。刺激シグナル伝達は、メディアストリームを介して、クライアント、またはリモートユーザーインターフェイスでローカルに実行されるユーザーインターフェイスで発生する可能性があります。刺激シグナル伝達には、ハイパーリンクのクリックから、ボタンを押すこと、従来のデュアルトーンマルチ周波数（DTMF）入力まで、広範囲のメカニズムが含まれます。すべての場合において、刺激シグナルは、そのフレームワークで重要な役割を果たしているマークアップ言語の使用を通じてサポートされます。
This framework proposes a decomposed component architecture with a very loose coupling of services and components. This means that a service (such as a conferencing server or an auto-attendant) need not be implemented as an actual server. Rather, these services can be built by combining a few basic components in straightforward or arbitrarily complex ways.
このフレームワークは、サービスとコンポーネントの非常に緩い結合を備えた分解されたコンポーネントアーキテクチャを提案しています。これは、サービス（会議サーバーや自動アテナントなど）を実際のサーバーとして実装する必要はないことを意味します。むしろ、これらのサービスは、いくつかの基本的なコンポーネントを簡単にまたは任意に複雑な方法で組み合わせることで構築できます。
Since the components are easily deployed on separate boxes, by separate vendors, or even with separate providers, we achieve a separation of function that allows each piece to be developed in complete isolation. We can also reuse existing components for new applications. This allows rapid service creation, and the ability for services to be distributed across organizational domains anywhere in the Internet.
コンポーネントは、別々のベンダーによって、または個別のプロバイダーを使用して、個別のボックスに簡単に展開されるため、各ピースを完全に分離して開発できるようにする機能の分離を実現します。また、新しいアプリケーション用に既存のコンポーネントを再利用することもできます。これにより、迅速なサービスの作成と、インターネット内のどこでも組織ドメイン全体にサービスを配布できるようになります。
For many of these components, it is also desirable to discover their capabilities, for example, querying the ability of a mixer to host a 10-dialog conference or to reserve resources for a specific time. These actions could be provided in the form of URIs, provided there is an a priori means of understanding their semantics. For example, if there is a published dictionary of operations, a way to query the service for the available operations and the associated URIs, the URI can be the interface for providing these service operations. This concept is described in more detail in the context of dialog operations in Section 3.
これらのコンポーネントの多くでは、たとえば、ミキサーが10ダイアログ会議を開催する機能を照会したり、特定の時間のためにリソースを予約する機能を照会することも望ましいです。これらのアクションは、彼らのセマンティクスを理解するための先験的な手段があれば、URIの形で提供できます。たとえば、公開されている操作辞書がある場合、利用可能な運用と関連するURIのサービスを照会する方法である場合、URIはこれらのサービス操作を提供するためのインターフェイスになります。この概念については、セクション3のダイアログ操作のコンテキストで詳細に説明します。
Media intermediaries are not participants in any conversation space, although an entity that is also a media translator may also have a co-located participant component (for example, a mixer that also announces the arrival of a new participant; the announcement portion is a participant, but the mixer itself is not). Media intermediaries should be as transparent as possible to the end users -- offering a useful, fundamental service without getting in the way of new features implemented by participants. Some common media intermediaries are described below.
メディアの仲介者は会話分野の参加者ではありませんが、メディア翻訳者でもあるエンティティには、共同所在地の参加者コンポーネントがいる場合があります（たとえば、新しい参加者の到着も発表するミキサーです。発表部分は参加者です。、しかし、ミキサー自体はそうではありません）。メディアの仲介者は、エンドユーザーに可能な限り透明である必要があります。参加者が実装する新機能の邪魔をすることなく、有用で基本的なサービスを提供します。いくつかの一般的なメディア仲介業者については、以下に説明します。
A SIP mixer is a component that combines media from all dialogs in the same conversation in a media-specific way. For example, the default combining for an audio conference might be an N-1 configuration, while a text mixer might interleave text messages on a per-line basis. More details about how to manipulate the media policy used by mixers is discussed in [XCON-CCMP].
SIPミキサーは、すべてのダイアログのメディアを同じ会話でメディア固有の方法で組み合わせたコンポーネントです。たとえば、オーディオカンファレンスのデフォルトの組み合わせはN-1構成である可能性がありますが、テキストミキサーはテキストメッセージを1行ごとにインターリーフする可能性があります。ミキサーが使用するメディアポリシーを操作する方法の詳細については、[XCON-CCMP]で説明します。
A transcoder translates media from one encoding or format to another (for example, GSM (Global System for Mobile communications) voice to G.711, MPEG2 to H.261, or text/html to text/plain), or from one media type to another (for example, text to speech). A more thorough discussion of transcoding is described in the SIP transcoding services invocation [RFC5369].
トランスコダーは、あるエンコードまたはフォーマットからメディアを別のエンコードまたはフォーマット（たとえば、GSM（モバイルコミュニケーション用のグローバルシステム）からG.711、MPEG2からH.261、またはテキスト/HTMLからテキスト/プレーン）に変換するか、1つのメディアタイプから別の人に（たとえば、テキストからスピーチ）。トランスコーディングのより徹底的な議論は、SIPトランスコーディングサービスの呼び出し[RFC5369]で説明されています。
A media relay terminates media and simply forwards it to a new destination without changing the content in any way. Sometimes, media relays are used to provide source IP address anonymity, to facilitate middlebox traversal, or to provide a trusted entity where media can be forcefully disconnected.
メディアリレーはメディアを終了し、コンテンツを何らかの形で変更せずに新しい目的地に転送するだけです。メディアリレーを使用して、ソースIPアドレスの匿名性を提供したり、ミドルボックスのトラバーサルを促進したり、メディアを強制的に切断できる信頼できるエンティティを提供するために使用されます。
A queue server is a location where calls can be entered into one of several FIFO (first-in, first-out) queues. A queue server would subscribe to the presence of groups or individuals who are interested in its queues. When detecting that a user is available to service a queue, the server redirects or transfers the last call in the relevant queue to the available user. On a queue-by-queue basis, authorized users could also subscribe to the call state (dialog information) of calls within a queue. Authorized users could use this information to effectively pluck (take) a call out of the queue (for example, by sending an INVITE with a Replaces header to one of the user agents in the queue).
キューサーバーは、コールをいくつかのFIFO（ファーストイン、ファーストアウト）キューの1つに入力できる場所です。キューサーバーは、キューに関心のあるグループまたは個人の存在を購読します。ユーザーがキューにサービスを提供できることを検出すると、サーバーは、利用可能なユーザーに関連するキューの最後の呼び出しをリダイレクトまたは転送します。キューごとに、認定ユーザーは、キュー内のコールのコール状態（ダイアログ情報）を購読することもできます。許可されたユーザーは、この情報を使用して、キューから効果的に呼び出し（たとえば、キュー内のユーザーエージェントの1人にヘッダーを交換する招待状を送信する）を効果的に引き抜くことができます。
A parking place is a location where calls can be terminated temporarily and then retrieved later. While a call is "parked", it can receive media "on hold" such as music, announcements, or advertisements. Such a service could be further decomposed such that announcements or music are handled by a separate component.
駐車場は、通話を一時的に終了し、後で取得できる場所です。コールは「駐車」されていますが、音楽、発表、広告など、「保留に」メディアを受信できます。このようなサービスは、発表や音楽が別のコンポーネントによって処理されるようにさらに分解される可能性があります。
An announcement server is a server that can play digitized media (frequently audio), such as music or recorded speech. These servers are typically accessible via SIP, HTTP (Hyper Text Transport Protocol), or RTSP (Real-Time Streaming Protocol). An analogous service is a recording service that stores digitized media. A convention for specifying announcements in SIP URIs is described in [RFC4240]. Likewise, the same server could easily provide a service that records digitized media.
アナウンスサーバーは、音楽や録画されたスピーチなど、デジタル化されたメディア（頻繁にオーディオ）を再生できるサーバーです。これらのサーバーは通常、SIP、HTTP（ハイパーテキストトランスポートプロトコル）、またはRTSP（リアルタイムストリーミングプロトコル）を介してアクセス可能です。類似のサービスは、デジタル化されたメディアを保存する録音サービスです。SIP URIで発表を指定するための条約は、[RFC4240]に記載されています。同様に、同じサーバーがデジタル化されたメディアを記録するサービスを簡単に提供できます。
A "voice dialog" is a model of spoken interactive behavior between a human and an automaton that can include synthesized speech, digitized audio, recognition of spoken and DTMF key input, a recording of spoken input, and interaction with call control. Voice dialogs frequently consist of forms or menus. Forms present information and gather input; menus offer choices of what to do next.
「音声ダイアログ」は、人間とオートマトンの間の音声インタラクティブな動作のモデルであり、合成された音声、デジタル化されたオーディオ、音声入力の認識、音声入力の記録、コールコントロールとの相互作用を含むことができます。音声ダイアログは、頻繁にフォームまたはメニューで構成されます。情報を提示し、入力を収集します。メニューは、次に何をすべきかの選択肢を提供します。
Spoken dialogs are a basic building block of applications that use voice. Consider, for example, that a voicemail system, the conference-id and passcode collection system for a conferencing system, and complicated voice-portal applications all require a voice-dialog component.
音声ダイアログは、音声を使用するアプリケーションの基本的な構成要素です。たとえば、ボイスメールシステム、会議システム用のConference-IDおよびPassCode Collection System、および複雑な音声ポータルアプリケーションにはすべて、ボイスダイアログコンポーネントが必要であることを考慮してください。
Text-to-speech (TTS) is a service that converts text into digitized audio. TTS is frequently integrated into other applications, but when separated as a component, it provides greater opportunity for broad reuse. Automatic Speech Recognition (ASR) is a service that attempts to decipher digitized speech based on a proposed grammar. Like TTS, ASR services can be embedded, or exposed so that many applications can take advantage of such services. A standardized (decomposed) interface to access standalone TTS and ASR services is currently being developed as described in [RFC4313].
Text-to-Speech（TTS）は、テキストをデジタル化されたオーディオに変換するサービスです。TTSは頻繁に他のアプリケーションに統合されますが、コンポーネントとして分離すると、幅広い再利用の機会が増えます。自動音声認識（ASR）は、提案された文法に基づいてデジタル化された音声を解読しようとするサービスです。TTSと同様に、ASRサービスは組み込み、または多くのアプリケーションがそのようなサービスを活用できるようにすることができます。[RFC4313]で説明されているように、スタンドアロンTTとASRサービスにアクセスするための標準化された（分解された）インターフェイスが現在開発されています。
VoiceXML is a W3C (World Wide Web Consortium) recommendation that was designed to give authors control over the spoken dialog between users and applications. The application and user take turns speaking: the application prompts the user, and the user in turn responds. Its major goal is to bring the advantages of web-based development and content delivery to interactive voice-response applications. We believe that VoiceXML represents the ideal partner for SIP in the development of distributed IVR (interactive voice response) servers. VoiceXML is an XML-based scripting language for describing IVR services at an abstract level. VoiceXML supports DTMF recognition, speech recognition, text-to-speech, and the playing out of recorded media files. The results of the data collected from the user are passed to a controlling entity through an HTTP POST operation. The controller can then return another script, or terminate the interaction with the IVR server.
VoiceXMLは、ユーザーとアプリケーションの間の話し言葉の対話を著者に制御できるように設計されたW3C（World Wide Web Consortium）の推奨事項です。アプリケーションとユーザーは順番に話します：アプリケーションはユーザーにプロンプトを促し、ユーザーは順番に応答します。その主な目標は、Webベースの開発とコンテンツ配信の利点をインタラクティブな音声応答アプリケーションにもたらすことです。VoiceXMLは、分散IVR（インタラクティブな音声応答）サーバーの開発においてSIPに理想的なパートナーであると考えています。VoiceXMLは、抽象レベルでIVRサービスを説明するためのXMLベースのスクリプト言語です。VoiceXMLは、DTMFの認識、音声認識、テキストへのスピーチ、および記録されたメディアファイルの再生をサポートしています。ユーザーから収集されたデータの結果は、HTTPポスト操作を介して管理エンティティに渡されます。コントローラーは、別のスクリプトを返すか、IVRサーバーとの相互作用を終了することができます。
A VoiceXML server also need not be implemented as a monolithic server. Figure 4 shows a diagram of a VoiceXML browser that is split into media and non-media handling parts. The VoiceXML interpreter handles SIP dialog state and state within a VoiceXML document, and sends requests to the media component over another protocol.
VoiceXMLサーバーもモノリシックサーバーとして実装する必要はありません。図4は、メディアと非メディアの処理部品に分割されたvoiceXMLブラウザの図を示しています。VoiceXMLインタープリターは、SIPダイアログ状態とvoiceXMLドキュメント内の状態を処理し、別のプロトコルを介してメディアコンポーネントにリクエストを送信します。
+-------------+
| |
| VoiceXML |
| Interpreter |
| (signaling) |
+-------------+
^ ^
| |
SIP | | RTSP
| |
| |
v v
+-------------+ +-------------+
| | | |
| SIP UA | RTP | RTSP Server |
| |<------>| (media) |
| | | |
+-------------+ +-------------+
Figure 4. Decomposed VoiceXML Server
図4.分解されたVoiceXMLサーバー
All naming in SIP uses URIs. URIs in SIP are used in a plethora of contexts: the Request-URI; Contact, To, From, and *-Info header fields; application/uri bodies; and embedded in email, web pages, instant messages, and ENUM records. The Request-URI identifies the user or service for which the call is destined.
SIPのすべての命名はURIを使用します。SIPのurisは、多くのコンテキストで使用されます。リクエスト-URI。連絡、、from、および *-infoヘッダーフィールド。アプリケーション/URI体;電子メール、Webページ、インスタントメッセージ、およびEnumレコードに埋め込まれています。リクエスト-URIは、通話が運命づけられているユーザーまたはサービスを識別します。
SIP URIs embedded in informational SIP header fields, SIP bodies, and non-SIP content can also specify methods, special parameters, header fields, and even bodies. For example:
情報提供SIPヘッダーフィールド、SIPボディ、および非SIPコンテンツに埋め込まれたSIP URIは、メソッド、特別なパラメーター、ヘッダーフィールド、さらにはボディを指定することもできます。例えば：
sip:bob@b.example.com;method=REFER?Refer-To=http://example.com/~alice Throughout this document, we discuss call control primitive operations. One of the biggest problems is defining how these operations may be invoked. There are a number of ways to do this. One way is to define the primitives in the protocol itself such that SIP methods (for example, REFER) or SIP header fields (for example, Replaces) indicate a specific call control action. Another way to invoke call control primitives is to define a specific Request-URI naming convention. Either these conventions must be shared between the client (the invoker) and the server, or published by or on behalf of the server. The former involves defining URI construction techniques (e.g., URI parameters and/or token conventions) as proposed in [RFC4240]. The latter technique usually involves discovering the URI via a SIP event package, a web page, a business card, or an instant message. Yet, another means to acquire the URIs is to define a dictionary of primitives with well-defined semantics and provide a means to query the named primitives and corresponding URIs that may be invoked on the service or dialogs.
sip：bob@b.example.com; method =参照？紹介= http：//example.com/~aliceこのドキュメント全体で、コールコントロールプリミティブ操作について説明します。最大の問題の1つは、これらの操作がどのように呼び出されるかを定義することです。これを行う方法はいくつかあります。1つの方法は、Protocol自体のプリミティブを定義することで、SIPメソッド（例を参照）またはSIPヘッダーフィールド（たとえば、置換）が特定のコールコントロールアクションを示すことです。コールコントロールプリミティブを呼び出す別の方法は、特定のリクエスト-URI命名規則を定義することです。これらの規則は、クライアント（インボーカー）とサーバーの間で共有されるか、サーバーによってまたはサーバーに代わって公開される必要があります。前者は、[RFC4240]で提案されているように、URI構築技術（URIパラメーターやトークン規則など）を定義することを伴います。後者の手法では、通常、SIPイベントパッケージ、Webページ、名刺、またはインスタントメッセージを介してURIを発見することが含まれます。しかし、URISを取得する別の手段は、明確に定義されたセマンティクスを持つプリミティブの辞書を定義し、サービスまたはダイアログに呼び出される可能性のある名前のプリミティブと対応するURIを照会する手段を提供することです。
An address-of-record, or public SIP address, is a SIP (or Secure SIP (SIPS)) URI that points to a domain with a location service that can map the URI to set of Contact URIs where the user might be available. Typically, the Contact URIs are populated via registration.
録音アドレスまたはパブリックSIPアドレスは、SIP（またはセキュアSIP（SIP））URIで、ユーザーが利用可能になる可能性のあるURIをマッピングできるURIをマッピングできるロケーションサービスを備えたドメインを指します。通常、コンタクトは登録によって入力されます。
Address-of-Record Contacts
録音アドレス連絡先
sip:bob@biloxi.example.com -> sip:bob@babylon.biloxi.example.com:5060
sip:bbrown@mailbox.provider.example.net
sip:+1.408.555.6789@mobile.example.net
Callee Capabilities [RFC3840] define a set of additional parameters to the Contact header field that define the characteristics of the user agent at the specified URI. For example, there is a mobility parameter that indicates whether the UA is fixed or mobile. When a user agent registers, it places these parameters in the Contact header fields to characterize the URIs it is registering. This allows a proxy for that domain to have information about the contact addresses for that user.
Callee機能[RFC3840]指定されたURIでユーザーエージェントの特性を定義するコンタクトヘッダーフィールドに追加のパラメーターのセットを定義します。たとえば、UAが固定かモバイルかを示すモビリティパラメーターがあります。ユーザーエージェントが登録すると、これらのパラメーターをコンタクトヘッダーフィールドに配置して、登録しているURIを特徴付けます。これにより、そのドメインのプロキシがそのユーザーの連絡先アドレスに関する情報を持つことができます。
When a caller sends a request, it can optionally request Caller Preferences [RFC3841] by including the Accept-Contact, Request-Disposition, and Reject-Contact header fields that request certain handling by the proxy in the target domain. These header fields contain preferences that describe the set of desired URIs to which the caller would like their request routed. The proxy in the target domain matches these preferences with the Contact characteristics originally registered by the target user. The target user can also choose to run arbitrarily complex "Find-me" feature logic on a proxy in the target domain.
発信者がリクエストを送信すると、ターゲットドメインのプロキシによる特定の処理を要求する受け入れコンタクト、リクエスト拡散、拒否ヘッダーフィールドを含めることにより、オプションで発信者の設定[RFC3841]を要求できます。これらのヘッダーフィールドには、発信者がリクエストをルーティングしたい目的のurisのセットを記述する設定が含まれています。ターゲットドメインのプロキシは、これらの設定と一致し、ターゲットユーザーが元々登録した連絡先特性と一致します。ターゲットユーザーは、ターゲットドメインのプロキシで任意に複雑な「Find-ME」機能ロジックを実行することもできます。
There is a strong asymmetry in how preferences for callers and callees can be presented to the network. While a caller takes an active role by initiating the request, the callee takes a passive role in waiting for requests. This motivates the use of callee-supplied scripts and caller preferences included in the call request. This asymmetry is also reflected in the appropriate relationship between caller and callee preferences. A server for a callee should respect the wishes of the caller to avoid certain locations, while the preferences among locations has to be the callee's choice, as it determines where, for example, the phone rings and whether the callee incurs mobile telephone charges for incoming calls.
発信者とCalleesの好みをネットワークに提示する方法には、強い非対称性があります。発信者はリクエストを開始することで積極的な役割を果たしますが、Calleeはリクエストを待つ際に受動的な役割を果たします。これにより、Callee-Suppliedスクリプトとコールリクエストに含まれる発信者の好みの使用が動機付けられます。この非対称性は、発信者とCalleeの好みの適切な関係にも反映されています。Calleeのサーバーは、特定の場所を避けるために発信者の希望を尊重する必要がありますが、場所間の設定はCalleeの選択である必要があります。電話。
SIP User Agent implementations are encouraged to make intelligent decisions based on the type of participants (active/passive, hidden, human/robot) in a conversation space. This information is conveyed via the dialog package or in a SIP header field parameter communicated using an appropriate SIP header field. For example, a music on hold service may take the sensible approach that if there are two or more unhidden participants, it should not provide hold music; or that it will not send hold music to robots.
SIPユーザーエージェントの実装は、会話スペースで参加者（アクティブ/パッシブ、非表示、人間/ロボット）の種類に基づいてインテリジェントな決定を下すことをお勧めします。この情報は、ダイアログパッケージを介して、または適切なSIPヘッダーフィールドを使用して通信されたSIPヘッダーフィールドパラメーターで伝えられます。たとえば、Hold On Holdサービスは、2人以上の非表示の参加者がいる場合、Hold Musicを提供するべきではないという賢明なアプローチをとることがあります。または、ロボットにホールドミュージックを送信しないこと。
Multiple participants in the same conversation space may represent the same human user. For example, the user may use one participant device for video, chat, and whiteboard media on a PC and another for audio media on a SIP phone. In this case, the address-of-record is the same for both user agents, but the Contacts are different. In this case, there is really only one human participant. In addition, human users may add robot participants that act on their behalf (for example, a call recording service or a calendar announcement reminder). Call control features in SIP should continue to function as expected in such an environment.
同じ会話スペースの複数の参加者は、同じ人間のユーザーを表す場合があります。たとえば、ユーザーは、PCでビデオ、チャット、ホワイトボードメディアに1つの参加者デバイスを使用し、SIP電話でオーディオメディアに別の参加者を使用することができます。この場合、レコードアドレスは両方のユーザーエージェントで同じですが、連絡先は異なります。この場合、実際には人間の参加者が1人だけです。さらに、人間のユーザーは、自分に代わって行動するロボット参加者を追加する場合があります（たとえば、コールレコーディングサービスやカレンダーの発表リマインダー）。SIPの呼び出し制御機能は、そのような環境で予想どおりに機能し続ける必要があります。
A critical piece of defining a session-level service that can be accessed by SIP is defining the naming of the resources within that service. This point cannot be overstated.
SIPでアクセスできるセッションレベルのサービスを定義する重要な部分は、そのサービス内のリソースの命名を定義することです。この点を誇張することはできません。
In the context of SIP control of application components, we take advantage of the fact that the left-hand side of a standard SIP URI is a user part. Most services may be thought of as user automatons that participate in SIP sessions. It naturally follows that the user part should be utilized as a service indicator.
アプリケーションコンポーネントのSIP制御のコンテキストでは、標準のSIP URIの左側がユーザーの部分であるという事実を利用します。ほとんどのサービスは、SIPセッションに参加するユーザーオートマトンと考えられる場合があります。当然、ユーザーパーツをサービスインジケーターとして利用する必要があることになります。
For example, media servers commonly offer multiple services at a single host address. Use of the user part as a service indicator enables service consumers to direct their requests without ambiguity. It has the added benefit of enabling media services to register their availability with SIP Registrars just as any "real" SIP user would. This maintains consistency and provides enhanced flexibility in the deployment of media services in the network.
たとえば、メディアサーバーは通常、単一のホストアドレスで複数のサービスを提供します。サービスインジケーターとしてユーザーパーツを使用すると、サービス消費者は曖昧さなくリクエストを指示できます。「実際の」SIPユーザーと同じように、メディアサービスがSIPレジストラに可用性を登録できるようにするという利点があります。これにより、一貫性が維持され、ネットワーク内のメディアサービスの展開における柔軟性が向上します。
There has been much discussion about the potential for confusion if media-service URIs are not readily distinguishable from other types of SIP UAs. The use of a service namespace provides a mechanism to unambiguously identify standard interfaces while not constraining the development of private or experimental services.
メディアサービスURIが他のタイプのSIP UAと容易に区別できない場合、混乱の可能性について多くの議論がありました。サービスネームスペースを使用すると、プライベートまたは実験サービスの開発を制約しないように、標準インターフェイスを明確に識別するメカニズムが提供されます。
In SIP, the Request-URI identifies the user or service for which the call is destined. The great advantage of using URIs (specifically, the SIP Request-URI) as a service identifier comes because of the combination of two facts. First, unlike in the PSTN (Public Switched Telephone Network), where the namespace (dialable telephone numbers) is limited, URIs come from an infinite space. They are plentiful, and they are free. Secondly, the primary function of SIP is call routing through manipulations of the Request-URI. In the traditional SIP application, this URI represents a person. However, the URI can also represent a service, as we propose here. This means we can apply the routing services SIP provides to the routing of calls to services. The result -- the problem of service invocation and service location becomes a routing problem, for which SIP provides a scalable and flexible solution. Since there is such a vast namespace of services, we can explicitly name each service in a finely granular way. This allows the distribution of services across the network. For further discussion about services and SIP URIs, see RFC 3087 [RFC3087].
SIPでは、リクエスト-URIは、通話が運命づけられているユーザーまたはサービスを識別します。URI（具体的には、SIPリクエストURI）をサービス識別子として使用するという大きな利点は、2つの事実の組み合わせのために発生します。第一に、名前空間（ダイヤル可能な電話番号）が制限されているPSTN（公開された電話ネットワーク）とは異なり、URIは無限のスペースから来ています。彼らは豊富で、自由です。第二に、SIPの主な機能は、リクエスト-URIの操作を介した呼び出しルーティングです。従来のSIPアプリケーションでは、このURIは人を表しています。ただし、ここで提案するように、URIもサービスを表すことができます。これは、SIPが提供するルーティングサービスをサービスへの通話のルーティングに適用できることを意味します。結果 - サービスの呼び出しとサービスの場所の問題はルーティングの問題になり、SIPはスケーラブルで柔軟なソリューションを提供します。このような広大なサービスの名前空間があるため、各サービスを細かく粒状に明示的に名前を付けることができます。これにより、ネットワーク全体のサービスを分配できます。サービスとSIP URIに関する詳細については、RFC 3087 [RFC3087]を参照してください。
Consider a conferencing service, where we have separated the names of ad hoc conferences from scheduled conferences, we can program proxies to route calls for ad hoc conferences to one set of servers and calls for scheduled ones to another, possibly even in a different provider. In fact, since each conference itself is given a URI, we can distribute conferences across servers, and easily guarantee that calls for the same conference always get routed to the same server. This is in stark contrast to conferences in the telephone network, where the equivalent of the URI -- the phone number -- is scarce. An entire conferencing provider generally has one or two numbers. Conference IDs must be obtained through IVR interactions with the caller or through a human attendant. This makes it difficult to distribute conferences across servers all over the network, since the PSTN routing only knows about the dialed number.
アドホック会議の名前をスケジュールされた会議から分離した会議サービスを検討してください。アドホック会議の呼び出しを1つのサーバーにルーティングするためにプロキシをプログラムし、別のプロバイダーでも、スケジュールされたものの呼び出しを別のプロバイダーにさえプログラムできます。実際、各会議自体にはURIが与えられているため、サーバー全体に会議を配布し、同じ会議の呼び出しが常に同じサーバーにルーティングされることを簡単に保証できます。これは、URIに相当する電話番号が少ない電話ネットワークでの会議とはまったく対照的です。一般に、会議プロバイダー全体に1つまたは2つの数字があります。会議IDは、発信者とのIVR相互作用または人間のアテンダントを通じて取得する必要があります。これにより、PSTNルーティングはダイヤル番号のみを知っているため、ネットワーク全体のサーバー全体に会議を配布することが困難になります。
For more examples, consider the URI conventions of RFC 4240 [RFC4240] for media servers and RFC 4458 [RFC4458] for voicemail and IVR systems.
その他の例については、メディアサーバーのRFC 4240 [RFC4240]およびボイスメールおよびIVRシステムのRFC 4458 [RFC4458]のURI規則を検討してください。
In practical applications, it is important that an invoker does not necessarily apply semantic rules to various URIs it did not create. Instead, it should allow any arbitrary string to be provisioned, and map the string to the desired behavior. The administrator of a service may choose to provision specific conventions or mnemonic strings, but the application should not require it. In any large installation, the system owner is likely to have preexisting rules for mnemonic URIs, and any attempt by an application to define its own rules may create a conflict. Implementations should allow an arbitrary mix of URIs from these schemes, or any other scheme that renders valid SIP URIs, rather than enforce only one particular scheme.
実際のアプリケーションでは、招待者が作成しなかったさまざまなURIに必ずしもセマンティックルールを適用しないことが重要です。代わりに、任意の文字列をプロビジョニングし、文字列を目的の動作にマッピングできるようにする必要があります。サービスの管理者は、特定の規則またはニーモニック文字列を提供することを選択できますが、アプリケーションはそれを必要としないはずです。大規模なインストールでは、システム所有者はニーモニックURIの既存のルールを持っている可能性が高く、アプリケーションによる独自のルールを定義する試みは競合を作成する可能性があります。実装では、これらのスキームからのURIの任意の組み合わせ、または特定のスキームを1つだけ実施するのではなく、有効なSIP URIをレンダリングする他のスキームを可能にする必要があります。
As we have shown, SIP URIs represent an ideal, flexible mechanism for describing and naming service resources, regardless of whether the resources are queues, conferences, voice dialogs, announcements, voicemail treatments, or phone features.
私たちが示したように、SIP URIは、リソースがキュー、会議、音声の対話、発表、ボイスメール治療、または電話の機能であるかどうかにかかわらず、サービスリソースを説明および名前を付ける理想的で柔軟なメカニズムを表しています。
With functional signaling, only the invoker of features in SIP needs to know exactly which feature they are invoking. One of the primary benefits of this approach is that combinations of functional features work in SIP call control without requiring complex feature-interaction matrices. For example, let us examine the combination of a "transfer" of a call that is "conferenced".
機能的なシグナリングを使用すると、SIPの機能の招待者のみが、どの機能が呼び出されているかを正確に知る必要があります。このアプローチの主な利点の1つは、機能機能の組み合わせが複雑な機能相互作用マトリックスを必要とせずにSIPコールコントロールで機能することです。たとえば、「授与される」コールの「転送」の組み合わせを調べてみましょう。
Alice calls Bob. Alice silently "conferences in" her robotic assistant Albert as a hidden party. Bob transfers Alice to Carol. If Bob asks Alice to Replace her leg with a new one to Carol, then both Alice and Albert should be communicating with Carol (transparently).
アリスはボブに電話します。アリスは、隠されたパーティーとしてロボットアシスタントのアルバートを静かに「会議」します。ボブはアリスをキャロルに転送します。ボブがアリスに彼女の足を新しいキャロルに置き換えるように頼むなら、アリスとアルバートの両方がキャロルとコミュニケーションをとるべきです（透過的に）。
Using the peer-to-peer model, this combination of features works fine if A is doing local mixing (Alice replaces Bob's dialog with Carol's), or if A is using a central mixer (the mixer replaces Bob's dialog with Carol's). A clever implementation using the 3pcc model can generate similar results.
ピアツーピアモデルを使用して、この機能の組み合わせは、Aがローカルミキシングを行っている場合（アリスがボブのダイアログをキャロルに置き換えます）、またはAが中央ミキサーを使用している場合（ミキサーがボブのダイアログをキャロルに置き換える）場合に正常に機能します。3PCCモデルを使用した巧妙な実装は、同様の結果を生成できます。
New extensions to the SIP Call Control Framework should attempt to preserve this property.
SIPコールコントロールフレームワークへの新しい拡張機能は、このプロパティを保存しようとする必要があります。
Billing in the PSTN is typically based on who initiated a call. At the moment, billing in a SIP network is neither consistent with itself nor with the PSTN. (A billing model for SIP should allow for both PSTN-style billing and non-PSTN billing.) The example below demonstrates one such inconsistency.
PSTNでの請求は、通常、誰が電話を開始したかに基づいています。現時点では、SIPネットワークでの請求は、それ自体ともPSTNと一致していません。（SIPの請求モデルは、PSTNスタイルの請求と非PSTN請求の両方を許可する必要があります。）以下の例は、そのような矛盾の1つを示しています。
Alice places a call to Bob. Alice then blind transfers Bob to Carol through a PSTN gateway. In current usage of REFER, Bob may be billed for a call he did not initiate (his UA originated the outgoing dialog, however). This is not necessarily a terrible thing, but it demonstrates a security concern (Bob must have appropriate local policy to prevent fraud). Also, Alice may wish to pay for Bob's session with Carol. There should be a way to signal this in SIP.
アリスはボブに電話をかけます。その後、アリスはPSTNゲートウェイを介してボブをキャロルに転送します。紹介の現在の使用では、ボブは彼が開始しなかった電話に対して請求される場合があります（しかし、彼のUAは発信ダイアログを発信しました）。これは必ずしもひどいことではありませんが、セキュリティ上の懸念を示しています（ボブは詐欺を防ぐために適切なローカルポリシーを持っている必要があります）。また、アリスはキャロルとのボブのセッションの代金を支払うことを望んでいるかもしれません。SIPでこれを信号する方法があるはずです。
Likewise, a Replacement call may maintain the same billing relationship as a Replaced call, so if Alice first calls Carol, then asks Bob to Replace this call, Alice may continue to receive a bill.
同様に、交換コールは交換されたコールと同じ請求関係を維持する場合があるため、アリスが最初にキャロルに電話した場合、ボブにこのコールを交換するように頼む場合、アリスは引き続き請求書を受け取ることができます。
Further work in SIP billing should define a way to set or discover the direction of billing.
SIP請求のさらなる作業では、請求の方向を設定または発見する方法を定義する必要があります。
Call control actions can be categorized by the dialogs upon which they operate. The actions may involve a single or multiple dialogs. These dialogs can be early or established. Multiple dialogs may be related in a conversation space to form a conference or other interesting media topologies.
コールコントロールアクションは、動作するダイアログによって分類できます。アクションには、単一または複数のダイアログが含まれる場合があります。これらのダイアログは、早期または確立できます。会話の分野やその他の興味深いメディアトポロジを形成するための会話の分野には、複数のダイアログが関連している場合があります。
It should be noted that it is desirable to provide a means by which a party can discover the actions that may be performed on a dialog. The interested party may be independent or related to the dialogs. One means of accomplishing this is through the ability to define and obtain URIs for these actions, as described in Section 2.7.2.
当事者がダイアログで実行される可能性のあるアクションを発見できる手段を提供することが望ましいことに注意する必要があります。利害関係者は独立しているか、ダイアログに関連している場合があります。これを達成する1つの手段は、セクション2.7.2で説明されているように、これらのアクションのURIを定義および取得する能力を通じてです。
Below are listed several call control "actions" that establish or modify dialogs and relate the participants in a conversation space. The names of the actions listed are for descriptive purposes only (they are not normative). This list of actions is not meant to be exhaustive.
以下に、ダイアログを確立または変更し、参加者を会話分野に関連付けるいくつかのコールコントロール「アクション」をリストします。リストされているアクションの名前は、説明的な目的のみです（規範ではありません）。このアクションのリストは、網羅的であることを意図したものではありません。
In the examples, all actions are initiated by the user "Alice" represented by UA "A".
例では、すべてのアクションは、UA「A」で表されるユーザー「アリス」によって開始されます。
The following are a set of actions that may be performed on a single early dialog. These actions can be thought of as a set of remote control operations. For example, an automaton might perform the operation on behalf of a user. Alternatively, a user might use the remote control in the form of an application to perform the action on the early dialog of a UA that may be out of reach. All of these actions correspond to telling the UA how to respond to a request to establish an early dialog. These actions provide useful functionality for PDA-, PC-, and server-based applications that desire the ability to control a UA. A proposed mechanism for this type of functionality is described in remote call control [FEATURE-REF].
以下は、単一の初期ダイアログで実行できるアクションのセットです。これらのアクションは、一連のリモートコントロール操作と考えることができます。たとえば、オートマトンはユーザーに代わって操作を実行する場合があります。あるいは、ユーザーはアプリケーションの形式でリモートコントロールを使用して、手の届かないUAの初期のダイアログでアクションを実行する場合があります。これらのアクションはすべて、初期のダイアログを確立するための要求に応答する方法をUAに伝えることに対応しています。これらのアクションは、UAを制御する能力を希望するPDA、PC、およびサーバーベースのアプリケーションに有用な機能を提供します。このタイプの機能の提案されたメカニズムは、リモートコールコントロール[Feature-Ref]で説明されています。
A dialog is in some early dialog state such as 180 Ringing. It may be desirable to tell the UA to answer the dialog. That is, tell it to send a 200 OK response to establish the dialog.
ダイアログは、180リンギングなどの初期のダイアログ状態にあります。ダイアログに答えるようにUAに指示することが望ましい場合があります。つまり、ダイアログを確立するために200のOK応答を送信するように伝えます。
It may be desirable to tell the UA to respond with a 3xx class response to forward an early dialog to another UA.
UAに、3xXクラスの応答で応答して、初期のダイアログを別のUAに転送することが望ましい場合があります。
It may be desirable to instruct the UA to send an error response such as 486 Busy Here.
ここでは486などのエラー応答を送信するようにUAに指示することが望ましい場合があります。
There is another useful set of actions that operate on a single established dialog. These operations are useful in building productivity applications for aiding users in controlling their phones. For example, a Customer Relationship Management (CRM) application that sets up calls for a user eliminating the need for the user to actually enter an address. These operations can also be thought of as remote control actions. A proposed mechanism for this type of functionality is described in remote call control [FEATURE-REF].
単一の確立されたダイアログで動作する別の有用なアクションセットがあります。これらの操作は、ユーザーが携帯電話の制御を支援するための生産性アプリケーションを構築するのに役立ちます。たとえば、ユーザーが実際にアドレスを入力する必要性を排除するユーザーを設定する顧客関係管理（CRM）アプリケーション。これらの操作は、リモートコントロールアクションとも考えることもできます。このタイプの機能の提案されたメカニズムは、リモートコールコントロール[Feature-Ref]で説明されています。
This action instructs the UA to initiate a dialog. This action can be performed using the REFER method.
このアクションは、UAにダイアログを開始するように指示します。このアクションは、参照方法を使用して実行できます。
This action instructs the UA to put an established dialog on hold. Though this operation can conceptually be performed with the REFER method, there are no semantics defined as to what the referred party should do with the SDP. There is no way to distinguish between the desire to go on or off hold on a per-media stream basis.
このアクションは、UAに確立されたダイアログを保留するように指示します。この操作は概念的に紹介方法で実行できますが、紹介された当事者がSDPに対して何をすべきかに関して定義されたセマンティクスはありません。メディアごとのストリームに基づいて、オンまたはオフオフにしたいという欲求を区別する方法はありません。
This action instructs the UA to terminate an early or established dialog. A REFER request with the following Refer-To URI and Target-Dialog header field [RFC4538] performs this action. Note: this example does not show the full set of header fields.
このアクションは、UAに早期または確立されたダイアログを終了するように指示します。次の紹介リクエストは、URIおよびターゲットダイアログヘッダーフィールド[RFC4538]を参照して、このアクションを実行します。注：この例は、ヘッダーフィールドの完全なセットを示していません。
REFER sip:carol@client.chicago.net SIP/2.0
Refer-To: sip:bob@babylon.biloxi.example.com;method=BYE
Target-Dialog: 13413098;local-tag=879738;remote-tag=023214
These actions apply to a set of related dialogs.
これらのアクションは、関連するダイアログのセットに適用されます。
This section describes how call transfer can be achieved using centralized (3pcc) and peer-to-peer (REFER) approaches.
このセクションでは、集中化（3PCC）およびピアツーピア（参照）アプローチを使用して、コール転送を達成する方法について説明します。
The conversation space changes as follows:
会話スペースは次のように変更されます。
before after
{ A , B } --> { C , B }
A replaces itself with C.
Aはそれ自体をCに置き換えます
To make this happen using the peer-to-peer approach, "A" would send two SIP requests. A shorthand for those requests is shown below:
ピアツーピアアプローチを使用してこれを実現するために、「A」は2つのSIPリクエストを送信します。これらのリクエストの速記を以下に示します。
REFER B Refer-To:C BYE B
参照B参照：C Bye b
To make this happen using the 3pcc approach instead, the controller sends requests represented by the shorthand below:
代わりに3PCCアプローチを使用してこれを実現するために、コントローラーは以下の速記で表されるリクエストを送信します。
INVITE C (w/SDP of B) reINVITE B (w/SDP of C) BYE A Features enabled by this action:
c（bのw/sdp）bite re reinvite b（c of c of c of cのw/sdp）は、このアクションによって有効になっている特徴を別にします。
- blind transfer - transfer to a central mixer (some type of conference or forking) - transfer to park server (park) - transfer to music on hold or announcement server - transfer to a "queue" - transfer to a service (such as voice-dialog service) - transition from local mixer to central mixer
- ブラインド転送 - セントラルミキサーへの転送（何らかのタイプの会議またはフォーキング） - パークサーバー（パーク）への転送 - 保留またはアナウンスサーバーに音楽に転送 - 「キュー」に転送 - サービスに転送（音声など - ダイアログサービス） - ローカルミキサーからセントラルミキサーへの移行
This action is frequently referred to as "completing an attended transfer". It is described in more detail in [RFC5589].
このアクションは、頻繁に「出席した転送の完了」と呼ばれます。[RFC5589]で詳細に説明します。
Note that if a transfer requires URI hiding or privacy, then the 3pcc approach can more easily implement this. For example, if the URI of C needs to be hidden from B, then the use of 3pcc helps accomplish this.
転送にURIの隠れまたはプライバシーが必要な場合、3PCCアプローチはこれをより簡単に実装できることに注意してください。たとえば、CのURIをBから非表示にする必要がある場合、3PCCを使用するとこれが達成されます。
The conversation space changes as follows:
会話スペースは次のように変更されます。
{ B , C } --> { B , A }
A forcibly replaces C with itself. In most uses of this primitive, A is just "un-replacing" itself.
Aは強制的にCをそれ自体に置き換えます。この原始のほとんどの用途では、Aは単なる「非表現」そのものです。
Using the peer-to-peer approach, "A" sends:
ピアツーピアアプローチを使用して、「a」は次のとおりです。
INVITE B Replaces: <dialog between B and C>
Using the 3pcc approach (all requests sent from controller):
3PCCアプローチを使用します（コントローラーから送信されたすべてのリクエスト）：
INVITE A (w/SDP of B) reINVITE B (w/SDP of A) BYE C
a（bのw/sdp）reinvite b（w/sdp of aのw/sdp）byecを招待するc
Features enabled by this action:
このアクションによって有効になっている機能：
- transferee completes an attended transfer - retrieve from central mixer (not recommended) - retrieve from music on hold or park - retrieve from queue - call center take - voice portal resuming ownership of a call it originated - answering-machine style screening (pickup) - pickup of a ringing call (i.e., early dialog) Note that pick up of a ringing call has perhaps some interesting additional requirements. First of all, it is an early dialog as opposed to an established dialog. Secondly, the party that is to pick up the call may only wish to do so only while it is an early dialog. That is in the race condition where the ringing UA accepts just before it receives signaling from the party wishing to take the call, the taking party wishes to yield or cancel the take. The goal is to avoid yanking an answered call from the called party.
- Transfereeは参加した転送を完了します - セントラルミキサーから取得（推奨されていません） - ホールドまたはパークから音楽から取得 - キューから取得 - コールセンターテイク - コールの所有権の再開リンギングコールのピックアップ（つまり、早期ダイアログ）リンギングコールのピックアップには、おそらく興味深い追加要件があることに注意してください。まず、確立されたダイアログとは対照的に、それは初期の対話です。第二に、コールを拾うことになる当事者は、それが初期の対話である間にのみそうすることを望むかもしれません。それは、リンギングUAが電話をかけたいと望んでいる当事者から信号を受信する直前に受け入れるレース条件であり、テイクパーティーはテイクを降伏またはキャンセルすることを望んでいます。目標は、呼び出されたパーティーからの回答済みの電話を手にしないようにすることです。
This action is described in Replaces [RFC3891] and in [RFC5589].
このアクションは、[RFC3891]および[RFC5589]の置換で説明されています。
Note that the following four actions are described in [RFC4579].
次の4つのアクションが[RFC4579]で説明されていることに注意してください。
This is merely adding a participant to a SIP conference. The conversation space changes as follows:
これは、参加者をSIP会議に追加するだけです。会話スペースは次のように変更されます。
{ A , B } --> { A , B , C }
A adds C to the conversation.
Aは会話にCを追加します。
Using the peer-to-peer approach, adding a party using local mixing requires no signaling. To transition from a two-party call or a locally mixed conference to central mixing, A could send the following requests:
ピアツーピアアプローチを使用して、ローカルミキシングを使用してパーティーを追加するには、シグナリングは必要ありません。2人のパーティーコールまたはローカルな混合会議からセントラルミキシングに移行するには、次のリクエストを送信できます。
REFER B Refer-To: conference-URI INVITE conference-URI BYE B
参照Bを参照：Conference-URI Invite Conference-URI Bye b
To add a party to a conference:
会議にパーティーを追加するには：
REFER C Refer-To: conference-URI or REFER conference-URI Refer-To: C
参照c参照：Conference-uriまたは紹介Conference-uri参照：c
Using the 3pcc approach to transition to centrally mixed, the controller would send:
3PCCアプローチを使用して中央混合に移行するために、コントローラーは次のことを送信します。
INVITE mixer leg 1 (w/SDP of A) INVITE mixer leg 2 (w/SDP of B) INVITE C (late SDP) reINVITE A (w/SDP of mixer leg 1) reINVITE B (w/SDP of mixer leg 2) INVITE mixer leg3 (w/SDP of C)
招待ミキサーレッグ1（aのw/sdp）招待ミキサーレッグ2（bのsdp）招待C（後期SDP）リネバイトa（ミキサーレッグ1のw/sdp）リネバイトB（ミキサーレッグ2のSDP w/sdp）ミキサーleg3を招待します（cのsdp w/sdp）
To add a party to a SIP conference:
SIP会議にパーティーを追加するには：
INVITE C (late SDP) INVITE conference-URI (w/SDP of C)
招待C（後期SDP）Conference-URI（CのSDP w/sdp）を招待する
Features enabled:
有効になっている機能：
- standard conference feature - call recording - answering-machine style screening (screening)
- 標準的な会議機能 - コールレコーディング - 回答マシンスタイルのスクリーニング（スクリーニング）
The conversation space changes like this:
会話スペースはこのように変わります：
{ A , B } , { A , C } --> { A , B , C }
or like this
またはこのように
{ A , B } , { C , D } --> { A , B , C , D }
A takes two conversation spaces and joins them together into a single space.
Aは2つの会話スペースを取り、それらを単一のスペースに結合します。
Using the peer-to-peer approach, A can mix locally, or REFER the participants of both conversation spaces to the same central mixer (as in Section 3.3.5).
ピアツーピアアプローチを使用して、A Can Canはローカルで混合するか、両方の会話スペースの参加者を同じ中央ミキサーに紹介します（セクション3.3.5のように）。
For the 3pcc approach, the call flows for inserting participants, and joining and splitting conversation spaces are tedious yet straightforward, so these are left as an exercise for the reader.
3PCCアプローチでは、コールが参加者を挿入し、会話スペースに参加して分割するための流れは退屈でありながら簡単です。したがって、これらは読者の演習として残されます。
Features enabled:
有効になっている機能：
- standard conference feature - leaving a sidebar to rejoin a larger conference
- 標準的な会議機能 - より大きな会議に再び参加するためにサイドバーを残す
The conversation space changes like this:
会話スペースはこのように変わります：
{ B , C } --> { A , B , C }
A inserts itself into a conversation space.
会話の空間に挿入します。
A proposed mechanism for signaling this using the peer-to-peer approach is to send a new header field in an INVITE with "joining" [RFC3911] semantics. For example: INVITE B Join: <dialog id of B and C>
ピアツーピアアプローチを使用してこれを合図するための提案されたメカニズムは、「結合」[RFC3911]セマンティクスを招待して新しいヘッダーフィールドを招待して送ることです。例：招待B結合：<bのダイアログIDとc>
If B accepted the INVITE, B would accept responsibility to set up the dialogs and mixing necessary (for example, to mix locally or to transfer the participants to a central mixer).
Bが招待を受け入れた場合、Bはダイアログをセットアップして必要なミキシングの責任を受け入れます（たとえば、ローカルで混合したり、参加者を中央ミキサーに転送したりするため）。
Features enabled:
有効になっている機能：
- barge-in - call center monitoring - call recording
- Barge -in-コールセンター監視 - 呼び出し録音
{ A , B , C , D } --> { A , B } , { C , D }
If using a central conference with peer-to-peer
ピアツーピアとの中央会議を使用する場合
REFER C Refer-To: conference-URI (new URI) REFER D Refer-To: conference-URI (new URI) BYE C BYE D
参照c紹介：Conference-uri（new URI）紹介d紹介：rebrion：conference-uri（new uri）bye c bye d
Features enabled:
有効になっている機能：
- sidebar conversations during a larger conference
- 大規模な会議中のサイドバーの会話
A participates in two conversation spaces simultaneously:
2つの会話スペースに同時に参加します。
{ A, B } --> { B , A } & { A , C }
A is a participant in two conversation spaces such that A sends the same media to both spaces, and renders media from both spaces, presumably by mixing or rendering the media from both. We can define that A is the "anchor" point for both forks, each of which is a separate conversation space.
Aは2つの会話スペースの参加者であり、Aは両方のスペースに同じメディアを送信し、おそらく両方のメディアをミキシングまたはレンダリングすることにより、両方のスペースからメディアをレンダリングする。Aは両方のフォークの「アンカー」ポイントであることを定義できます。それぞれが別の会話スペースです。
This action is purely local implementation (it requires no special signaling). Local features such as switching calls between the background and foreground are possible using this media relationship.
このアクションは純粋にローカルな実装です（特別なシグナル伝達は必要ありません）。このメディア関係を使用して、背景と前景の間の通話の切り替えなどのローカル機能が可能です。
The conversation space diagram.
会話空間図。
{ A, B } --> { A , B } & { B , C } A requests B to be the "anchor" of two conversation spaces.
{a、b} - > {a、b}＆{b、c} aは、2つの会話スペースの「アンカー」であることを要求します。
This is easily set up by creating a conference with two sub-conferences and setting the media policy appropriately such that B is a participant in both. Media forking can also be set up using 3pcc, as described in Section 5.1 of RFC 3264 [RFC3264] (an offer/answer model for SDP). The session descriptions for forking are quite complex. Controllers should verify that endpoints can handle forked media, for example, using prior configuration.
これは、2つのサブ会議で会議を作成し、Bが両方の参加者になるようにメディアポリシーを適切に設定することで簡単に設定されます。RFC 3264 [RFC3264]（SDPのオファー/回答モデル）のセクション5.1で説明されているように、メディアフォーキングは3PCCを使用してセットアップすることもできます。フォーキングのセッションの説明は非常に複雑です。コントローラーは、エンドポイントがフォークされたメディアを処理できることを確認する必要があります。たとえば、以前の構成を使用してください。
Features enabled:
有効になっている機能：
- barge-in - voice-portal services - whisper - key word detection - sending DTMF somewhere else
- Barge -in -Voice -Portal Services -Whisper-キーワード検出 - DTMFのどこか別の場所
Call control primitives provide a powerful set of features that can be dangerous in the hands of an attacker. To complicate matters, call control primitives are likely to be automatically authorized without direct human oversight.
コールコントロールプリミティブは、攻撃者の手に危険になる可能性のある強力な機能セットを提供します。問題を複雑にするために、コントロールコントロールプリミティブは、直接的な人間の監視なしに自動的に承認される可能性があります。
The class of attacks that are possible using these tools includes the ability to eavesdrop on calls, disconnect calls, redirect calls, render irritating content (including ringing) at a user agent, cause an action that has billing consequences, subvert billing (theft-of-service), and obtain private information. Call control extensions must take extra care to describe how these attacks will be prevented.
これらのツールを使用して可能な攻撃のクラスには、通話を盗聴する、通話の切断、呼び出しのリダイレクト、ユーザーエージェントでの刺激的なコンテンツ（リンギングを含む）のレンダリング、請求の結果を持つアクション、請求（盗難（盗難）を引き起こす機能が含まれます。-Service）、および個人情報を取得します。コールコントロール拡張機能は、これらの攻撃がどのように防止されるかを説明するために特別な注意を払う必要があります。
We can also make some general observations about authorization and trust with respect to call control. The security model is dramatically dependent on the signaling model chosen (see Section 2.3)
また、コールコントロールに関する認可と信頼について一般的な観察を行うこともできます。セキュリティモデルは、選択されたシグナリングモデルに劇的に依存しています（セクション2.3を参照）
Let us first examine the security model used in the 3pcc approach. All signaling goes through the controller, which is a trusted entity. Traditional SIP authentication and hop-by-hop encryption and message integrity work fine in this environment, but end-to-end encryption and message integrity may not be possible.
最初に3PCCアプローチで使用されるセキュリティモデルを調べてみましょう。すべてのシグナリングは、信頼できるエンティティであるコントローラーを通過します。従来のSIP認証とホップバイホップ暗号化とメッセージの整合性は、この環境では正常に機能しますが、エンドツーエンドの暗号化とメッセージの整合性は不可能かもしれません。
When using the peer-to-peer approach, call control actions and primitives can be legitimately initiated by a) an existing participant in the conversation space, b) a former participant in the conversation space, or c) an entity trusted by one of the participants. For example, a participant always initiates a transfer; a retrieve from park (a take) is initiated on behalf of a former participant, and a barge-in (insert or far-fork) is initiated by a trusted entity (an operator, for example).
ピアツーピアアプローチを使用する場合、コールコントロールアクションとプリミティブは、a）会話スペースの既存の参加者、b）会話スペースの前の参加者、またはc）の1人によって信頼されるエンティティによって合法的に開始される可能性があります。参加者。たとえば、参加者は常に転送を開始します。パークからの回収（テイク）は、元参加者に代わって開始され、バージイン（挿入またはファーフォーク）は、信頼できるエンティティ（たとえばオペレーター）によって開始されます。
Authenticating requests by an existing participant or a trusted entity can be done with baseline SIP mechanisms. In the case of features initiated by a former participant, these should be protected against replay attacks, e.g., by using a unique name or identifier per invocation. The Replaces header field exhibits this behavior as a by-product of its operation (once a Replaces operation is successful, the dialog being Replaced no longer exists). These credentials may, for example, need to be passed transitively or fetched in an event body.
既存の参加者または信頼できるエンティティによる認証要求は、ベースラインSIPメカニズムで実行できます。元参加者によって開始された機能の場合、これらは、たとえば、呼び出しごとに一意の名前または識別子を使用することにより、リプレイ攻撃から保護する必要があります。交換ヘッダーフィールドは、この動作の副産物としてこの動作を示します（置換操作が成功すると、置き換えられるダイアログは存在しなくなります）。たとえば、これらの資格情報は、イベントボディに渡されるか、イベントボディで取得する必要がある場合があります。
To authorize call control primitives that trigger special behavior (such as an INVITE with Replaces or Join semantics), the receiving user agent may have trouble finding appropriate credentials with which to challenge or authorize the request, as the sender may be completely unknown to the receiver, except through the introduction of a third party. These credentials need to be passed transitively in some way or fetched in an event body, for example.
特別な動作をトリガーするコールコントロールプリミティブ（交代やセマンティクスに参加するなど）を承認するには、受信ユーザーエージェントは、リクエストに挑戦または承認する適切な資格情報を見つけるのに苦労する可能性があります。、第三者の導入を除いて。これらの資格情報は、たとえば、何らかの方法で一時的に合格するか、イベントボディでフェッチする必要があります。
Standard SIP privacy and anonymity mechanisms such as [RFC3323] and [RFC3325] used during SIP session establishment apply equally well to SIP call control operations. SIP call control mechanisms should address privacy and anonymity issues associated with that operation. For example, privacy during a transfer operation using REFER is discussed in Section 7.2 of [RFC5589]
SIPセッションの確立中に使用される[RFC3323]や[RFC3325]などの標準的なSIPプライバシーと[RFC3325]などの匿名メカニズムは、SIPコールコントロール操作にも同様に適用されます。SIPコールコントロールメカニズムは、その操作に関連するプライバシーと匿名性の問題に対処する必要があります。たとえば、紹介を使用した転送操作中のプライバシーについては、[RFC5589]のセクション7.2で説明しています。
Primitives are defined in terms of their ability to provide features. These example features should require an amply robust set of services to demonstrate a useful set of primitives. They are described here briefly. Note that the descriptions of these features are non-normative. Note also that this document describes a mixture of both features originating in the world of telephones and features that are clearly Internet oriented.
プリミティブは、機能を提供する能力の観点から定義されます。これらの例の機能には、有用なプリミティブセットを実証するために、十分に堅牢なサービスセットが必要です。ここで簡単に説明します。これらの機能の説明は非規範的であることに注意してください。また、このドキュメントは、電話の世界に由来する両方の機能と、明らかにインターネット指向の機能の混合物を説明していることに注意してください。
Appendix A.1. Attended Transfer
付録A.1。出席した転送
In Attended Transfer [RFC5589], the transferring party establishes a session with the transfer target before completing the transfer.
出席した転送[RFC5589]では、転送を完了する前に転送ターゲットとのセッションを確立します。
Appendix A.2. Auto Answer
付録A.2。自動応答
In Auto Answer, calls to a certain address or URI answer immediately via a speakerphone. The Answer-Mode header field [RFC5373] can be used for this feature.
自動回答では、スピーカーフォンを介して特定のアドレスまたはURIの回答をすぐに呼び出します。この機能には、回答モードヘッダーフィールド[RFC5373]を使用できます。
Appendix A.3. Automatic Callback
付録A.3。自動コールバック
In Automatic Callback [RFC5359], Alice calls Bob, but Bob is busy. Alice would like Bob to call her automatically when he is available. When Bob hangs up, Alice's phone rings. When Alice answers, Bob's phone rings. Bob answers and they talk.
自動コールバック[RFC5359]では、アリスはボブに電話しますが、ボブは忙しいです。アリスは、彼が利用可能なときにボブに自動的に電話してほしいと思っています。ボブが電話を切ると、アリスの電話が鳴ります。アリスが答えると、ボブの電話が鳴ります。ボブは答えて、彼らは話します。
Appendix A.4. Barge-In
付録A.4。バージイン
In Barge-in, Carol interrupts Alice who has an in-progress call with Bob. In some variations, Alice forcibly joins a new conversation with Carol, in other variations, all three parties are placed in the same conversation (basically a three-way conference). Barge-in works the same as call monitoring except that it must indicate that the send media stream be mixed so that all of the other parties can hear the stream from the UA that is barging in.
バージインでは、キャロルはボブと進行中の電話をかけているアリスを中断します。いくつかのバリエーションでは、アリスはキャロルとの新しい会話に強制的に参加します。他のバリエーションでは、3つのパーティーすべてが同じ会話に掲載されます（基本的には3方向会議）。Barge-Inは、他のすべての当事者がGISで入っているUAからストリームを聞くことができるように、送信メディアストリームが混合されていることを示す必要があることを除いて、コールモニタリングと同じように機能します。
Appendix A.5. Blind Transfer
付録A.5。ブラインドトランスファー
In Blind Transfer [RFC5589], Alice is in a conversation with Bob. Alice asks Bob to contact Carol, but makes no attempt to contact Carol independently. In many implementations, Alice does not verify Bob's success or failure in contacting Carol.
ブラインドトランスファー[RFC5589]では、アリスはボブと会話しています。アリスはボブにキャロルに連絡するように頼みますが、独立してキャロルに連絡しようとはしません。多くの実装では、アリスはボブの成功やキャロルへの連絡における失敗を確認しません。
Appendix A.6. Call Forwarding
付録A.6。コール転送
In call forwarding [RFC5359], before a dialog is accepted, it is redirected to another location, for example, because the originally intended recipient is busy, does not answer, is disconnected from the network, or has configured all requests to go elsewhere.
コール転送[RFC5359]では、ダイアログを受け入れる前に、たとえば、元々意図された受信者が忙しく、回答せず、ネットワークから切断されない、または他の場所に行くすべてのリクエストを構成しているため、別の場所にリダイレクトされます。
Appendix A.7. Call Monitoring
付録A.7。監視を呼び出します
Call monitoring is a Join operation [RFC3911]. For example, a call center supervisor joins an in-progress call for monitoring purposes. The monitoring UA sends a Join to the dialog to which it wants to listen. It is able to discover the dialog via the dialog state on the monitored UA. The monitoring UA sends SDP in the INVITE that indicates receive-only media. As the UA is only monitoring, it does not matter whether the UA indicates it wishes the send stream to be mixed or point to point.
通話監視は結合操作[RFC3911]です。たとえば、コールセンターのスーパーバイザーは、監視目的で進行中の電話に参加します。監視UAは、聞きたいダイアログに結合を送信します。監視されているUA上のダイアログ状態を介してダイアログを発見することができます。監視UAは、受信専用メディアを示す招待状でSDPを送信します。UAは監視のみであるため、UAが送信ストリームを混合またはポイントツーポイントにすることを望んでいることを示すかどうかは関係ありません。
Appendix A.8. Call Park
付録A.8。公園に電話してください
In Call Park [RFC5359], a participant parks a call (essentially puts the call on hold), and then retrieves it at a later time (typically from another location). Call park requires the ability to put a dialog some place, advertise it to users in a pickup group, and to uniquely identify it in a means that can be communicated (including human voice). The dialog can be held locally on the UA parking the dialog or alternatively transferred to the park service for the pickup group. The parked dialog then needs to be labeled (e.g., orbit 12) in a way that can be communicated to the party that is to pick up the call. The UAs in the pickup group discover the parked dialog(s) via the dialog package from the park service. If the dialog is parked locally, the park service merely aggregates the parked call states from the set of UAs in the pickup group.
Call Park [RFC5359]では、参加者が電話をかけ（基本的にコールを保留にします）、後でそれを取得します（通常は別の場所から）。Call Parkには、ダイアログをある場所に配置し、ピックアップグループのユーザーに宣伝し、伝達できる手段（人間の声を含む）で独自に識別する機能が必要です。ダイアログは、ダイアログを駐車するUAでローカルに保持することも、ピックアップグループのパークサービスに転送されます。駐車されたダイアログには、電話を拾うためのパーティーに伝えることができる方法で、駐車したダイアログにラベルを付ける必要があります。ピックアップグループのUASは、パークサービスからのダイアログパッケージを介して駐車されたダイアログを発見します。ダイアログがローカルに駐車されている場合、パークサービスは、ピックアップグループのUASのセットから駐車中のコール状態を集約するだけです。
Appendix A.9. Call Pickup
付録A.9。ピックアップに電話します
There are two different features that are called Call Pickup [RFC5359]. The first is the pickup of a parked dialog. The UA from which the dialog is to be picked up subscribes to the dialog state of the park service or the UA that has locally parked the dialog. Dialogs that are parked should be labeled with an identifier. The labels are used by the UA to allow the user to indicate which dialog is to be picked up. The UA picking up the call invoked the URI in the call state that is labeled as replace-remote.
コールピックアップ[RFC5359]と呼ばれる2つの異なる機能があります。1つ目は、駐車したダイアログのピックアップです。ダイアログがピックアップされるUAは、パークサービスのダイアログ状態またはダイアログを局所的に駐車したUAを購読します。駐車されているダイアログには、識別子にラベルを付ける必要があります。ラベルはUAによって使用され、ユーザーがどのダイアログをピックアップするかを示すことができます。コールをピックアップするUAは、交換リモートとしてラベル付けされているコール状態のURIを呼び出しました。
The other call pickup feature involves picking up an early dialog (typically ringing). A party picks up a call that was ringing at another location. One variation allows the caller to choose which location, another variation just picks up any call in that user's "pickup group". This feature uses some of the same primitives as the pickup of a parked call. The call state of the UA ringing phone is advertised using the dialog package. The UA that is to pick up the early dialog subscribes either directly to the ringing UA or to a service aggregating the states for UAs in the pickup group. The call state identifies early dialogs. The UA uses the call state(s) to help the user choose which early dialog is to be picked up. The UA then invokes the URI in the call state labeled as replace-remote.
もう1つのコールピックアップ機能には、初期のダイアログ（通常は鳴り響く）が含まれます。パーティーは、別の場所で鳴っている電話を受け取ります。1つのバリエーションにより、発信者はどの場所を選択できます。別のバリエーションは、そのユーザーの「ピックアップグループ」の呼び出しを選択するだけです。この機能は、駐車したコールのピックアップと同じプリミティブの一部を使用しています。UAリンギング電話の呼び出し状態は、ダイアログパッケージを使用して宣伝されます。初期のダイアログをピックアップするUAは、リンギングUAまたはピックアップグループのUAの州を集約するサービスに直接購読します。コール状態は、早期ダイアログを識別します。UAは、コール状態を使用して、ユーザーがどの早期ダイアログを選択するかを選択できるようにします。次に、UAは、交換リモートとしてラベル付けされたコールステートのURIを呼び出します。
Appendix A.10. Call Return
付録A.10。呼び出しますreturn
In Call Return, Alice calls Bob. Bob misses the call or is disconnected before he is finished talking to Alice. Bob invokes Call return, which calls Alice, even if Alice did not provide her real identity or location to Bob.
コールリターンでは、アリスはボブに電話します。ボブは電話を逃したり、アリスと話を終える前に切断されます。ボブは、アリスがボブに彼女の本当のアイデンティティや場所を提供しなかったとしても、アリスを呼ぶコールリターンを呼び出します。
Appendix A.11. Call Waiting
付録A.11。待ってください
In Call Waiting, Alice is in a call, then receives another call. Alice can place the first call on hold, and talk with the other caller. She can typically switch back and forth between the callers.
コール待機で、アリスは電話をかけてから、別の電話を受けます。アリスは最初の呼び出しを保留にし、他の発信者と話すことができます。彼女は通常、発信者間で前後に切り替えることができます。
Appendix A.12. Click-to-Dial
付録A.12。ダイアルをクリックします
In Click-to-Dial [RFC5359], Alice looks in her company directory for Bob. When she finds Bob, she clicks on a URI to call him. Her phone rings (or possibly answers automatically), and when she answers, Bob's phone rings. The application or server that hosts the Click-to-Dial application captures the URI to be dialed and can set up the call using 3pcc or can send a REFER request to the UA that is to dial the address. As users sometimes change their mind or wish to give up listing to a ringing or voicemail answered phone, this application illustrates the need to also have the ability to remotely hangup a call.
クリックツーダイアル[RFC5359]では、アリスはボブの会社ディレクトリを探しています。彼女がボブを見つけたとき、彼女はウリをクリックして彼に電話します。彼女の電話が鳴ります（またはおそらく自動的に答える）、そして彼女が答えると、ボブの電話が鳴ります。クリックツーダイアルアプリケーションをホストするアプリケーションまたはサーバーは、ダイヤルされるURIをキャプチャし、3PCCを使用して通話を設定するか、アドレスをダイヤルするUAに参照リクエストを送信できます。ユーザーが気が変わったり、リンギングまたはボイスメールに応答した電話にリストを放棄したい場合があるため、このアプリケーションはまた、コールをリモートでハングアップする能力を持つ必要性を示しています。
Appendix A.13. Conference Call
付録A.13。電話会議
In a Conference Call [RFC4579], there are three or more active, visible participants in the same conversation space.
電話会議[RFC4579]には、同じ会話分野に3人以上のアクティブで目に見える参加者がいます。
Appendix A.14. Consultative Transfer
付録A.14。協議編入
In Consultative Transfer [RFC5589], the transferring party establishes a session with the target and mixes both sessions together so that all three parties can participate, then disconnects leaving the transferee and transfer target with an active session.
コンサルティブ転送[RFC5589]では、移籍する当事者はターゲットとのセッションを確立し、両方のセッションを一緒にミックスして、3つの当事者すべてが参加できるようにし、譲受人を離れてターゲットをアクティブなセッションで転送することを切断します。
Appendix A.15. Distinctive Ring
付録A.15。独特のリング
In Distinctive Ring, incoming calls have different ring cadences or sample sounds depending on the From party, the To party, or other factors. The target UA either makes a local decision based on information in an incoming INVITE (To, From, Contact, Request-URI) or trusts an Alert-Info header field [RFC3261] provided by the caller or inserted by a trusted proxy. In the latter case, the UA fetches the content described in the URI (typically via HTTP) and renders it to the user.
特徴的なリングでは、着信コールは、パーティー、パーティー、またはその他の要因に応じて、異なるリングケーデンスまたはサンプル音を持っています。ターゲットUAは、着信の招待状（連絡先、リクエスト-URIへ）の情報に基づいてローカルな決定を下すか、発信者によって提供されるアラートINFOヘッダーフィールド[RFC3261]を信頼するか、信頼できるプロキシによって挿入されます。後者の場合、UAはURIで説明されているコンテンツ（通常はHTTP経由）を取得し、ユーザーにレンダリングします。
Appendix A.16. Do Not Disturb
付録A.16。邪魔しないでください
In Do Not Disturb, Alice selects the Do Not Disturb option. Calls to her either ring briefly or not at all and are forwarded elsewhere. Some variations allow specially authorized callers to override this feature and ring Alice anyway. Do Not Disturb is best implemented in SIP using presence [RFC3856].
邪魔しないで、アリスはオプションを妨害しないことを選択します。彼女への呼び出しは、一時的に鳴るかまったく鳴らないか、他の場所に転送されます。いくつかのバリエーションにより、特別に許可された発信者がこの機能をオーバーライドし、とにかくアリスを鳴らすことができます。Do Not Unterは、存在感[RFC3856]を使用してSIPで最適に実装されています。
Appendix A.17. Find-Me
付録A.17。私を見つけて
In Find-Me, Alice sets up complicated rules for how she can be reached (possibly using CPL (Call Processing Language) [RFC3880], presence [RFC3856], or other factors). When Bob calls Alice, his call is eventually routed to a temporary Contact where Alice happens to be available.
Find-Meでは、アリスは、彼女がどのように到達できるかについて複雑なルールを設定します（おそらくCPL（コール処理言語）[RFC3880]、存在[RFC3856]、またはその他の要因を使用）。ボブがアリスに電話をかけると、彼の電話は最終的にアリスが利用できる一時的な連絡先にルーティングされます。
Appendix A.18. Hotline
付録A.18。ホットライン
In Hotline, Alice picks up a phone and is immediately connected to the technical support hotline, for example. Hotline is also sometimes known as a Ringdown line.
ホットラインでは、アリスは電話を取り上げ、たとえばテクニカルサポートホットラインに直ちに接続されています。ホットラインは、リングダウンラインとしても知られています。
Appendix A.19. IM Conference Alerts
付録A.19。IMカンファレンスアラート
In IM Conference Alerts, a user receives a notification as an instant message whenever someone joins a conference in which they are already a participant.
IM Conference Alertsでは、誰かがすでに参加者である会議に参加するたびに、ユーザーはインスタントメッセージとして通知を受け取ります。
Appendix A.20. Inbound Call Screening
付録A.20。インバウンドコールスクリーニング
In Inbound Call Screening, Alice doesn't want to receive calls from Matt. Inbound Screening prevents Matt from disturbing Alice. In some variations, this works even if Matt hides his identity.
インバウンドコールスクリーニングでは、アリスはマットから電話を受けたくありません。インバウンドスクリーニングは、マットがアリスを邪魔するのを防ぎます。いくつかのバリエーションでは、マットが自分のアイデンティティを隠しても、これは機能します。
Appendix A.21. Intercom
付録A.21。インターホン
In Intercom, Alice typically presses a button on a phone that immediately connects to another user or phone and causes that phone to play her voice over its speaker. Some variations immediately set up two-way communications, other variations require another button to be pressed to enable a two-way conversation. The UA initiates a dialog using INVITE and the Answer-Mode: Auto header field as described in [RFC5373]. The called UA accepts the INVITE with a 200 OK and automatically enables the speakerphone.
インターコムでは、アリスは通常、電話のボタンを押して、すぐに別のユーザーまたは電話に接続し、その電話がスピーカーの上で彼女の音声を再生します。いくつかのバリエーションはすぐに双方向通信を設定しましたが、他のバリエーションでは、双方向の会話を可能にするために別のボタンを押す必要があります。UAは、[RFC5373]で説明されているように、InviteとAnswer-Mode：Auto Headerフィールドを使用してダイアログを開始します。呼び出されたUAは、200 OKで招待状を受け入れ、スピーカーフォンを自動的に有効にします。
Alternatively, this can be a local decision for the UA to auto answer based upon called-party identification.
あるいは、これは、呼び出されたパーティ識別に基づいて、UAが自動回答することをローカルな決定にすることができます。
Appendix A.22. Message Waiting
付録A.22。メッセージを待っています
In Message Waiting [RFC3842], Bob calls Alice when she has stepped away from her phone. When she returns, a visible or audible indicator conveys that someone has left her a voicemail message. The message waiting indication may also convey how many messages are waiting, from whom, at what time, and other useful pieces of information.
メッセージを待っている[RFC3842]で、ボブは電話から離れたときにアリスに電話します。彼女が戻ったとき、可視または可聴インジケーターは、誰かが彼女にボイスメールメッセージを残したことを伝えます。メッセージを待つ兆候は、何時に、何時に、その他の有用な情報を待っているか、その他の有用な情報を伝えるかもしれません。
Appendix A.23. Music on Hold
付録A.23。保留中の音楽
In Music on Hold [RFC5359], when Alice places a call with Bob on hold, it replaces its audio with streaming content such as music, announcements, or advertisements. Music on hold can be implemented a number of ways. One way is to transfer the held call to a holding service. When the UA wishes to take the call off hold, it basically performs a take on the call from the holding service. This involves subscribing to call state on the holding service and then invoking the URI in the call state labeled as replace-remote.
Hold [RFC5359]では、アリスがボブを保留にして電話をかけると、音楽、アナウンス、広告などのストリーミングコンテンツにオーディオを置き換えます。保留中の音楽は多くの方法で実装できます。1つの方法は、保留中のコールを保有サービスに転送することです。UAがコールオフホールドを削除したいとき、それは基本的にホールディングサービスからのコールの見解を実行します。これには、ホールディングサービスのコールステートをサブスクライブし、交換リモートとしてラベル付けされたコールステートのURIを呼び出すことが含まれます。
Alternatively, music on hold can be performed as a local mixing operation. The UA holding the call can mix in the music from the music service via RTP (i.e., an additional dialog) or RTSP or other streaming media source. This approach is simpler (i.e., the held dialog does not move so there is less chance of loosing them) from a protocol perspective, however it does use more LAN bandwidth and resources on the UA.
または、保留中の音楽は、ローカルミキシング操作として実行できます。コールを保持しているUAは、RTP（つまり、追加のダイアログ）またはRTSPまたはその他のストリーミングメディアソースを介して音楽サービスの音楽をミックスできます。このアプローチは、プロトコルの観点からより単純です（つまり、保持されているダイアログは動きませんので、それらを失う可能性が低くなります）が、UAでより多くのLAN帯域幅とリソースを使用します。
Appendix A.24. Outbound Call Screening
付録A.24。アウトバウンドコールスクリーニング
In Outbound Call Screening, Alice is paged and unknowingly calls a PSTN pay-service telephone number in the Caribbean, but local policy blocks her call, and possibly informs her why.
アウトバウンドコールスクリーニングでは、アリスがページングされ、知らないうちにカリブ海のPSTNペイサービスの電話番号を呼び出しますが、地元のポリシーは彼女の呼びかけをブロックし、おそらくその理由を知らせます。
Appendix A.25. Pre-Paid Calling
付録A.25。プリペイド通話
In Pre-paid Calling, Alice pays for a certain currency or unit amount of calling value. When she places a call, she provides her account number somehow. If her account runs out of calling value during a call, her call is disconnected or redirected to a service where she can purchase more calling value.
プリペイド通話では、アリスは特定の通貨または単位の召し価値を支払います。彼女が電話をかけると、彼女は何らかの形でアカウント番号を提供します。彼女のアカウントが通話中に呼び出し価値がなくなった場合、彼女の電話は、より多くの呼び出し価値を購入できるサービスに切断またはリダイレクトされます。
For prepaid calling, the user's media always passes through a device that is trusted by the pre-paid provider. This may be the other endpoint (for example, a PSTN gateway). In either case, an intermediary proxy or B2BUA can periodically verify the amount of time available on the pre-paid account, and use the session-timer extension to cause the trusted endpoint (gateway) or intermediary (media relay) to send a reINVITE before that time runs out. During the reINVITE, the SIP intermediary can re-verify the account and insert another session-timer header field.
プリペイド通話の場合、ユーザーのメディアは常に、プリペイドプロバイダーによって信頼されているデバイスを通過します。これは、他のエンドポイント（たとえば、PSTNゲートウェイ）かもしれません。どちらの場合でも、仲介者のプロキシまたはB2BUAは、プリペイドアカウントで利用可能な時間を定期的に検証し、セッションタイマー拡張機能を使用して、信頼できるエンドポイント（ゲートウェイ）または仲介者（メディアリレー）を前にリネバイトを送信することができます。その時間はなくなります。Reinviteの間、SIP仲介者はアカウントを再確認し、別のセッションタイマーヘッダーフィールドを挿入できます。
Note that while most pre-paid systems on the PSTN use an IVR to collect the account number and destination, this isn't strictly necessary for a SIP-originated prepaid call. SIP requests and SIP URIs are sufficiently expressive to convey the final destination, the provider of the prepaid service, the location from which the user is calling, and the prepaid account they want to use. If a pre-paid IVR is used, the mechanism described below (Voice Portals) can be combined as well.
PSTN上のほとんどのプリペイドシステムはIVRを使用してアカウント番号と目的地を収集しますが、これはSIP造影プリペイドコールに厳密に必要ではないことに注意してください。SIPリクエストとSIP URIは、最終目的地、プリペイドサービスのプロバイダー、ユーザーが呼び出している場所、および使用するプリペイドアカウントを伝えるのに十分に表現力があります。プリペイドIVRを使用すると、以下に説明するメカニズム（音声ポータル）も組み合わせることができます。
Appendix A.26. Presence-Enabled Conferencing
付録A.26。プレゼンス対応会議
In Presence-Enabled Conferencing, Alice wants to set up a conference call with Bob and Cathy when they all happen to be available (rather than scheduling a predefined time). The server providing the application monitors their status, and calls all three when they are all "online", not idle, and not in another call. This could be implemented using conferencing [RFC4579] and presence [RFC3264] primitives.
存在対応会議では、アリスは、事前定義された時間をスケジュールするのではなく、すべてが利用可能になったときに、ボブとキャシーとの電話会議を設定したいと考えています。アプリケーションを提供するサーバーは、そのステータスを監視し、3つすべてがすべて「オンライン」であり、アイドル状態ではなく、別の呼び出しではない場合に呼び出します。これは、会議[RFC4579]および存在感[RFC3264]プリミティブを使用して実装できます。
Appendix A.27. Single Line Extension/Multiple Line Appearance
付録A.27。シングルライン拡張/複数の線の外観
In Single Line Extension/Multiple Line Appearances, groups of phones are all treated as "extensions" of a single line or AOR. A call for one rings them all. As soon as one answers, the others stop ringing. If any extension is actively in a conversation, another extension can "pick up" and immediately join the conversation. This emulates the behavior of a home telephone line with multiple phones. Incoming calls ring all the extensions through basic parallel forking. Each extension subscribes to dialog events from each other extension. While one user has an active call, any other UA extension can insert itself into that conversation (it already knows the dialog information) in the same way as barge-in.
シングルライン拡張/複数の行の外観では、携帯電話のグループはすべて、単一のラインまたはAORの「拡張」として扱われます。1つの呼びかけはそれらをすべて鳴らします。1つの回答があるとすぐに、他の人は鳴るのをやめます。拡張機能が積極的に会話をしている場合、別の拡張機能が「ピックアップ」し、すぐに会話に参加できます。これにより、複数の電話で自宅の電話回線の動作がエミュレートされます。着信コールは、基本的な並列フォーキングを通じてすべての拡張機能を鳴らします。各拡張機能は、互いの拡張機能からのダイアログイベントを購読します。1人のユーザーにアクティブな呼び出しがありますが、他のUA拡張機能は、バージインと同じ方法でその会話（すでにダイアログ情報を知っている）に挿入できます。
When implemented using SIP, this feature is known as Shared Appearances of an AOR [BLISS-SHARED]. Extensions to the dialog package are used to convey appearance numbers (line numbers).
SIPを使用して実装された場合、この機能はAOR [Bliss-Shared]の共有外観として知られています。ダイアログパッケージへの拡張機能は、外観数（行番号）を伝えるために使用されます。
Appendix A.28. Speakerphone Paging
付録A.28。スピーカーフォンのページング
In Speakerphone Paging, Alice calls the paging address and speaks. Her voice is played on the speaker of every idle phone in a preconfigured group of phones. Speakerphone paging can be implemented using either multicast or through a simple multipoint mixer. In the multicast solution, the paging UA sends a multicast INVITE with send-only media in the SDP (see also [RFC3264]). The automatic answer and enabling of the speakerphone is a locally configured decision on the paged UAs. The paging UA sends RTP via the multicast address indicated in the SDP.
スピーカーフォンのページングで、アリスはページングの住所を呼び出して話します。彼女の声は、事前に設定された携帯電話のグループで、すべてのアイドル電話のスピーカーで演奏されます。スピーカーフォンのページングは、マルチキャストまたは単純なマルチポイントミキサーを使用して実装できます。マルチキャストソリューションでは、ページングUAはSDPで送信専用メディアを含むマルチキャストの招待状を送信します（[RFC3264]も参照）。スピーカーフォンの自動回答と有効化は、ページングされたUASに関するローカルで構成された決定です。ページングUAは、SDPに示されているマルチキャストアドレスを介してRTPを送信します。
The multipoint solution is accomplished by sending an INVITE to the multipoint mixer. The mixer is configured to automatically answer the dialog. The paging UA then sends REFER requests for each of the UAs that are to become paging speakers (the UA is likely to send out a single REFER that is parallel forked by the proxy server). The UAs performing as paging speakers are configured to automatically answer based upon caller identification (e.g., the To field, URI, or Referred-To header fields).
マルチポイントソリューションは、マルチポイントミキサーへの招待状を送信することで実現されます。ミキサーは、ダイアログに自動的に回答するように構成されています。ページングUAは、ページングスピーカーになる各UAの参照要求を送信します（UAは、プロキシサーバーによって並列フォークされた単一の紹介を送信する可能性があります）。ページングスピーカーとして実行されるUASは、発信者の識別に基づいて自動的に回答するように構成されています（たとえば、フィールド、URI、または参照ヘッダーフィールド）。
Finally, as a third option, the user agent can send a mass-invitation request to a conference server, which would create a conference and send INVITEs containing the Answer-Mode: Auto header field to all user agents in the paging group.
最後に、3番目のオプションとして、ユーザーエージェントは会議サーバーに大量招待リクエストを送信できます。これにより、会議が作成され、Answer-Mode：Auto Headerフィールドがページンググループのすべてのユーザーエージェントに招待状を送信できます。
Appendix A.29. Speed Dial
付録A.29。短縮ダイヤル
In Speed Dial, Alice dials an abbreviated number, enters an alias, or presses a special speed-dial button representing Bob. Her action is interpreted as if she specified the full address of Bob.
スピードダイヤルでは、アリスは短縮番号にダイヤルし、エイリアスに入り、ボブを表す特別なスピードダイヤルボタンを押します。彼女の行動は、彼女がボブの完全な住所を指定したかのように解釈されます。
Appendix A.30. Voice Message Screening
付録A.30。音声メッセージのスクリーニング
In Voice Message Screening, Bob calls Alice. Alice is screening her calls, so Bob hears Alice's voicemail greeting. Alice can hear Bob leave his message. If she decides to talk to Bob, she can take the call back from the voicemail system; otherwise, she can let Bob leave a message. This emulates the behavior of a home telephone answering machine.
音声メッセージのスクリーニングでは、ボブはアリスに電話します。アリスは彼女の電話を上映しているので、ボブはアリスのボイスメールの挨拶を聞きます。アリスはボブが彼のメッセージを残すのを聞くことができます。彼女がボブと話すことにした場合、彼女はボイスメールシステムからコールバックを引き戻すことができます。そうでなければ、彼女はボブにメッセージを残させることができます。これにより、自宅の電話留置機の動作がエミュレートされます。
At first, this is the same as Call Monitoring (Appendix A.7). In this case, the voicemail service is one of the UAs. The UA screening the message monitors the call on the voicemail service, and also subscribes to dialog information. If the user screening their messages decides to answer, they perform a take from the voicemail system (for example, send an INVITE with Replaces to the UA leaving the message).
最初は、これはコール監視と同じです（付録A.7）。この場合、ボイスメールサービスはUASの1つです。UAスクリーニングメッセージは、ボイスメールサービスの呼び出しを監視し、ダイアログ情報を購読します。メッセージをスクリーニングするユーザーが回答することを決定した場合、ボイスメールシステムからテイクを実行します（たとえば、メッセージを残してUAに交換した招待状を送信します）。
Appendix A.31. Voice Portal
付録A.31。音声ポータル
Voice Portal is service that allows users to access a portal site using spoken dialog interaction. For example, Alice needs to schedule a working dinner with her co-worker Carol. Alice uses a voice portal to check Carol's flight schedule, find a restaurant near her hotel, make a reservation, get directions there, and page Carol with this information. A voice portal is essentially a complex collection of voice dialogs used to access interesting content. One of the most desirable call control features of a Voice Portal is the ability to start a new outgoing call from within the context of the Portal (to make a restaurant reservation, or return a voicemail message, for example). Once the new call is over, the user should be able to return to the Portal by pressing a special key, using some DTMF sequence (e.g., a very long pound or hash tone), or by speaking a key word (e.g., "Main Menu").
Voice Portalは、ユーザーが音声ダイアログインタラクションを使用してポータルサイトにアクセスできるようにするサービスです。たとえば、アリスは同僚のキャロルと一緒に働く夕食をスケジュールする必要があります。アリスは音声ポータルを使用して、キャロルのフライトスケジュールを確認し、ホテルの近くのレストランを見つけ、予約をし、そこで道順を取得し、この情報を使用してページキャロルを使用します。音声ポータルは、基本的に、興味深いコンテンツにアクセスするために使用される音声ダイアログの複雑なコレクションです。音声ポータルの最も望ましいコールコントロール機能の1つは、ポータルのコンテキスト内から新しい発信コールを開始する機能です（たとえば、レストランの予約を行うか、ボイスメールメッセージを返します）。新しい呼び出しが終了すると、ユーザーは、DTMFシーケンス（非常に長いポンドまたはハッシュトーンなど）を使用して、またはキーワードを話すことで、特別なキーを押すことでポータルに戻ることができるはずです（例： "Main」メニュー"）。
In order to accomplish this, the Voice Portal starts with the following media relationship:
これを達成するために、音声ポータルは次のメディア関係から始まります。
{ User , Voice Portal }
{ユーザー、音声ポータル}
The user then asks to make an outgoing call. The Voice Portal asks the user to perform a far-fork. In other words, the Voice Portal wants the following media relationship:
その後、ユーザーは発信コールを行うように依頼します。音声ポータルは、ユーザーに遠いフォークを実行するように求めます。言い換えれば、音声ポータルは次のメディア関係を望んでいます。
{ Target , User } & { User , Voice Portal }
The Voice Portal is now just listening for a key word or the appropriate DTMF. As soon as the user indicates they are done, the Voice Portal takes the call from the old target, and we are back to the original media relationship.
音声ポータルは、キーワードまたは適切なDTMFを聞いているだけです。ユーザーが完了したことを示すとすぐに、音声ポータルは古いターゲットから呼び出しを受け、元のメディア関係に戻ります。
This feature can also be used by the account number and phone number collection menu in a pre-paid calling service. A user can press a DTMF sequence that presents them with the appropriate menu again.
この機能は、前払いの通話サービスのアカウント番号と電話番号の収集メニューでも使用できます。ユーザーは、適切なメニューを再度表示するDTMFシーケンスを押すことができます。
Appendix A.32. Voicemail
付録A.32。ボイスメール
In Voicemail, Alice calls Bob who does not answer or is not available. The call forwards to a voicemail server that plays Bob's greeting and records Alice's message for Bob. An indication is sent to Bob that a new message is waiting, and he retrieves the message at a later date. This feature is implemented using features such as Call Forwarding (Appendix A.6) and the History-Info header field [RFC4244] or voicemail URI convention [RFC4458] and Message Waiting [RFC3842] features.
ボイスメールでは、アリスはボブに電話をかけます。ボブは答えられないか、利用できません。コールは、ボブの挨拶を再生し、ボブに対するアリスのメッセージを記録するボイスメールサーバーに転送されます。新しいメッセージが待っていることをボブに兆候が送られ、彼は後日メッセージを取得します。この機能は、コール転送（付録A.6）、History-INFOヘッダーフィールド[RFC4244]、VoiceMail URI Convention [RFC4458]およびメッセージ待機[RFC3842]機能などの機能を使用して実装されています。
Appendix A.33. Whispered Call Waiting
付録A.33。ささやき声を待っていました
In Whispered Call Waiting, Alice is in a conversation with Bob. Carol calls Alice. Either Carol can "whisper" to Alice directly ("Can you get lunch in 15 minutes?"), or an automaton whispers to Alice informing her that Carol is trying to reach her.
ささやき声を待って、アリスはボブと会話をしています。キャロルはアリスに電話します。キャロルはアリスに直接「ささやく」ことができます（「15分で昼食をとることができますか？」）、またはオートマトンがアリスにささやき、キャロルが彼女に到達しようとしていることを知らせます。
The authors would like to acknowledge Ben Campbell for his contributions to the document and thank AC Mahendran, John Elwell, and Xavier Marjou for their detailed Working-Group review of the document. The authors would like to thank Magnus Nystrom for his review of the document.
著者は、ドキュメントへの貢献についてベン・キャンベルに感謝し、ACマヘンドラン、ジョン・エルウェル、ザビエル・マルジューに感謝します。著者は、ドキュメントのレビューについてMagnus Nystromに感謝したいと思います。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)- Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、A。、「セッション開始プロトコル（SIP） - 特定のイベント通知」、RFC 3265、2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008.
[RFC5359] Johnston、A.、Sparks、R.、Cunningham、C.、Donovan、S。、およびK. Summers、「セッション開始プロトコルサービスの例」、BCP 144、RFC 5359、2008年10月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725] Rosenberg、J.、Peterson、J.、Schulzrinne、H.、およびG. Camarillo、「セッション開始プロトコル（SIP）のサードパーティコールコントロール（3PCC）の最良の現在のプラクティス」、BCP 85、RFC 3725、2004年4月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「セッション開始プロトコル（SIP）参照法」、RFC 3515、2003年4月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891] Mahy、R.、Biggs、B。、およびR. Dean、「セッション開始プロトコル（SIP）」は「ヘッダー」、RFC 3891、2004年9月に置き換えられます。
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[RFC3911] Mahy、R。およびD. Petrie、「セッション開始プロトコル（SIP）「Header」に参加、RFC 3911、2004年10月。
[BLISS-PROBLEM] Rosenberg, J., "Basic Level of Interoperability for Session Initiation Protocol (SIP) Services (BLISS) Problem Statement", Work in Progress, March 2009.
[Bliss-Problem] Rosenberg、J。、「セッション開始プロトコル（SIP）サービス（Bliss）問題ステートメントの相互運用性の基本レベル」、2009年3月、Work in Progress。
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[RFC4235] Rosenberg、J.、Schulzrinne、H。、およびR. Mahy、「セッション開始プロトコル（SIP）の招待状のダイアログイベントパッケージ」、RFC 4235、2005年11月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575] Rosenberg、J.、Schulzrinne、H。、およびO. Levin、「会議州のセッション開始プロトコル（SIP）イベントパッケージ」、RFC 4575、2006年8月。
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[RFC3680] Rosenberg、J。、「登録のためのセッション開始プロトコル（SIP）イベントパッケージ」、RFC 3680、2004年3月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353] Rosenberg、J。、「セッション開始プロトコル（SIP）との会議のフレームワーク」、RFC 4353、2006年2月。
[RFC5629] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", RFC 5629, October 2009.
[RFC5629] Rosenberg、J。、「セッション開始プロトコル（SIP）におけるアプリケーションインタラクションのフレームワーク」、RFC 5629、2009年10月。
[RFC5369] Camarillo, G., "Framework for Transcoding with the Session Initiation Protocol (SIP)", RFC 5369, October 2008.
[RFC5369] Camarillo、G。、「セッション開始プロトコル（SIP）によるトランスコーディングのフレームワーク」、RFC 5369、2008年10月。
[XCON-CCMP] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", Work in Progress, February 2010.
[XCON-CCMP] Barnes、M.、Boulton、C.、Romano、S。、およびH. Schulzrinne、「集中会議操作プロトコル」、2010年2月の作業。
[RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, June 2009.
[RFC5589] Sparks、R.、Johnston、A。、およびD. Petrie、「セッション開始プロトコル（SIP）コールコントロール - 転送」、BCP 149、RFC 5589、2009年6月。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
[RFC4579] Johnston、A。およびO. Levin、「セッション開始プロトコル（SIP）コールコントロール - ユーザーエージェントの会議」、BCP 119、RFC 4579、2006年8月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）の発信者の好み」、RFC 3841、2004年8月。
[RFC3087] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001.
[RFC3087] Campbell、B。およびR. Sparks、「SIP Request-URIを使用したサービスコンテキストの制御」、RFC 3087、2001年4月。
[FEATURE-REF] Audet, F., Johnston, A., Mahy, R., and C. Jennings, "Feature Referral in the Session Initiation Protocol (SIP)", Work in Progress, February 2008.
[Feature-Ref] Audet、F.、Johnston、A.、Mahy、R。、およびC. Jennings、「セッション開始プロトコル（SIP）の特徴紹介」、2008年2月の作業進行中。
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[RFC4240] Burger、E.、van Dyke、J。、およびA. Spitzer、「SIP付きベーシックネットワークメディアサービス」、RFC 4240、2005年12月。
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)", RFC 4458, April 2006.
[RFC4458] Jennings、C.、Audet、F。、およびJ. Elwell、「VoicemailやInteractive Voice Response（IVR）などのアプリケーション用のセッション開始プロトコル（SIP）URI」、RFC 4458、2006年4月。
[RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
[RFC4538] Rosenberg、J。、「セッション開始プロトコル（SIP）でのダイアログ識別による認可を要求する」、RFC 4538、2006年6月。
[RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, October 2004.
[RFC3880] Lennox、J.、Wu、X。、およびH. Schulzrinne、「Call Processing Language（CPL）：インターネットテレフォニーサービスのユーザー制御用言語」、RFC 3880、2004年10月。
[RFC5373] Willis, D. and A. Allen, "Requesting Answering Modes for the Session Initiation Protocol (SIP)", RFC 5373, November 2008.
[RFC5373] Willis、D。およびA. Allen、「セッション開始プロトコル（SIP）の応答モードの要求」、RFC 5373、2008年11月。
[RFC3842] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[RFC3842] Mahy、R。、「セッション開始プロトコル（SIP）のメッセージの概要とメッセージ待機表示イベントパッケージ」、RFC 3842、2004年8月。
[BLISS-SHARED] Johnston, A., Soroushnejad, M., and V. Venkataramanan, "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)", Work in Progress, October 2009.
[Bliss-Shared] Johnston、A.、Soroushnejad、M。、およびV. Venkataramanan、「セッション開始プロトコル（SIP）のレコードアドレス（AOR）の共有外観（AOR）」、2009年10月の作業。
[RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4244] Barnes、M。、「リクエスト履歴情報のセッション開始プロトコル（SIP）の拡張」、RFC 4244、2005年11月。
[RFC4313] Oran, D., "Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources", RFC 4313, December 2005.
[RFC4313] Oran、D。、「自動音声認識（ASR）、スピーカー識別/スピーカー検証（SI/SV）、およびテキストツースピーチ（TTS）リソースの分散制御の要件」、RFC 4313、2005年12月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内での主張されたアイデンティティのセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、2002年11月。
Authors' Addresses
著者のアドレス
Rohan Mahy Unaffiliated
Rohan Mahyは関係ありません
EMail: rohan@ekabal.com
Robert Sparks Tekelec
ロバート・スパークス・テケレック
EMail: rjsparks@nostrum.com
Jonathan Rosenberg jdrosen.net
Jonathan Rosenberg Jdrosen.net
EMail: jdrosen@jdrosen.net
Dan Petrie SIPez
ダン・ペトリー・シペス
EMail: dan.ietf@sipez.com
Alan Johnston (editor) Avaya
アラン・ジョンストン（編集者）アヴァヤ
EMail: alan.b.johnston@gmail.com