Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 5897 jdrosen.net
Category: Informational June 2010
ISSN: 2070-1721
Identification of Communications Services
in the Session Initiation Protocol (SIP)
Abstract
抽象
This document considers the problem of service identification in the Session Initiation Protocol (SIP). Service identification is the process of determining the user-level use case that is driving the signaling being utilized by the user agent (UA). This document discusses the uses of service identification, and outlines several architectural principles behind the process. It identifies perils when service identification is not done properly -- including fraud, interoperability failures, and stifling of innovation. It then outlines a set of recommended practices for service identification.
この文書では、セッション開始プロトコル（SIP）におけるサービス識別の問題を検討します。サービス識別は、ユーザエージェント（UA）によって利用されるシグナル伝達を駆動しているユーザーレベルのユースケースを決定するプロセスです。このドキュメントでは、サービス識別の用途について説明し、プロセスの背後にあるいくつかのアーキテクチャの原則を概説します。詐欺、相互運用性の障害を含む、および技術革新の息苦しい - サービス識別が適切に行われていない場合には、危険を識別します。その後、サービス識別のための推奨事項のセットを概説します。
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc5897.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5897で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Services and Service Identification .............................4
3. Example Services ................................................6
3.1. IPTV vs. Multimedia ........................................6
3.2. Gaming vs. Voice Chat ......................................7
3.3. Gaming vs. Voice Chat #2 ...................................7
3.4. Configuration vs. Pager Messaging ..........................7
4. Using Service Identification ....................................8
4.1. Application Invocation in the User Agent ...................8
4.2. Application Invocation in the Network ......................9
4.3. Network Quality-of-Service Authorization ..................10
4.4. Service Authorization .....................................10
4.5. Accounting and Billing ....................................11
4.6. Negotiation of Service ....................................11
4.7. Dispatch to Devices .......................................11
5. Key Principles of Service Identification .......................12
5.1. Services Are a By-Product of Signaling ....................12
5.2. Identical Signaling Produces Identical Services ...........13
5.3. Do What I Say, Not What I Mean ............................14
5.4. Declarative Service Identifiers Are Redundant .............15
5.5. URIs Are Key for Differentiated Signaling .................15
6. Perils of Declarative Service Identification ...................16
6.1. Fraud .....................................................16
6.2. Systematic Interoperability Failures ......................17
6.3. Stifling of Service Innovation ............................18
7. Recommendations ................................................20
7.1. Use Derived Service Identification ........................20
7.2. Design for SIP's Negotiative Expressiveness ...............20
7.3. Presence ..................................................21
7.4. Intra-Domain ..............................................21
7.5. Device Dispatch ...........................................21
8. Security Considerations ........................................22
9. Acknowledgements ...............................................22
10. Informative References ........................................22
The Session Initiation Protocol (SIP) [RFC3261] defines mechanisms for initiating and managing communications sessions between agents. SIP allows for a broad array of session types between agents. It can manage audio sessions, ranging from low-bitrate voice-only up to multi-channel high-fidelity music. It can manage video sessions, ranging from small, "talking-head" style video chat, up to high-definition multipoint video conferencing and ranging from low-bandwidth user-generated content, up to high-definition movie and TV content. SIP endpoints can be anything -- adaptors that convert an old analog telephone to Voice over IP (VoIP), dedicated hardphones, fancy hardphones with rich displays and user entry capabilities, softphones on a PC, buddy-list and presence applications on a PC, dedicated videoconferencing peripherals, and speakerphones.
セッション開始プロトコル（SIP）[RFC3261]はエージェント間の通信セッションを開始し、管理するためのメカニズムを定義します。 SIPは、エージェント間のセッションタイプの広範囲を可能にします。これは、低ビットレート音声専用マルチチャンネルの高忠実度の音楽まで至るまで、オーディオセッションを管理することができます。これは、高精細マルチポイントビデオ会議までのスタイルのビデオチャット、「頭の話」と高精細映画やテレビコンテンツまで、低帯域幅のユーザー生成コンテンツに至るまで、小さな至るまで、ビデオセッションを管理することができます。 SIPエンドポイントは何もすることができます - ボイスオーバーIPに古いアナログ電話（VoIPの）を変換アダプタ、専用のハードフォン、豊かなディスプレイとユーザー入力機能を備えた派手なハードフォン、PC上のPC、バディリストとプレゼンスアプリケーション上のソフトフォン、専用のビデオ会議周辺機器、およびスピーカー。
This breadth of applicability is SIP's greatest asset, but it also introduces numerous challenges. One of these is that, when an endpoint generates a SIP INVITE for a session, or receives one, that session can potentially be within the context of any number of different use cases and endpoint types. For example, a SIP INVITE with a single audio stream could represent a Push-To-Talk session between mobile devices, a VoIP session between softphones, or audio-based access to stored content on a server.
適用のこの広さは、SIPの最大の資産であるが、それはまた、多くの課題を紹介します。これらの一つは、エンドポイントがSIPセッションのためにINVITEを生成、または1つを受信した場合、そのセッションは、潜在的に異なるユースケースとエンドポイントタイプの任意の数のコンテキスト内であることができる、ということです。例えば、SIP単一のオーディオストリームとINVITEは、ソフトフォン、またはサーバー上で保存されたコンテンツへの音声アクセスの間のVoIPセッションをモバイルデバイス間のプッシュツートークセッションを表すことができます。
Each of these different use cases represents a different service. The service is the user-visible use case that is driving the behavior of the user agents and servers in the SIP network.
これらの異なる使用例はそれぞれ異なるサービスを表します。サービスは、SIPネットワークにおけるユーザエージェントとサーバの動作を駆動しているユーザに見えるユースケースです。
The differing services possible with SIP have driven implementors and system designers to seek techniques for service identification. Service identification is the process of determining and/or signaling the specific use case that is driving the signaling being generated by a user agent. At first glance, this seems harmless and easy enough. It is tempting to define a new header, "Service-ID", for example, and have a user agent populate it with any number of well-known tokens that define what the service is. It could then be consumed for any number of purposes. A token placed into the signaling for this purpose is called a service identifier.
SIPで可能な異なるサービスは、サービス識別のための技術を追求するために実装し、システム設計を牽引してきました。サービス識別は、決定及び/又はユーザエージェントによって生成されるシグナル伝達を駆動している特定のユースケースをシグナリングするプロセスです。一見すると、これは無害と十分に簡単そうです。それは、新しいヘッダを定義するために誘惑され、「サービスID」、例えば、ユーザエージェントがサービスとは何かを定義し、よく知られたトークンの任意の数を移入しています。次に、それを目的に、任意の数のために消費することができます。この目的のためにシグナリングに入れトークンはサービス識別子と呼ばれています。
Service identification and service identifiers, when used properly, can be beneficial. However, when done improperly, service identification can lead to fraud, systemic interoperability failures, and a complete stifling of the innovation that SIP was meant to achieve. The purpose of this document is to describe service identification in more detail and describe how these problems arise.
適切に使用すれば、サービス識別とサービス識別子は、有益であり得ます。不適切行われたときしかし、サービス識別は詐欺、全身の相互運用性の障害、およびSIPを達成するために意図された技術革新の完全な息苦しいにつながることができます。このドキュメントの目的は、より詳細にサービス識別を記述し、これらの問題が発生する方法を記述することです。
Section 2 begins by defining a service and the service identification problem. Section 3 gives some concrete examples of services and why they can be challenging to identify. Section 4 explores the ways in which a service identification can be utilized within a network. Next, Section 5 discusses the key architectural principles of service identification. Section 6 describes what declarative service invocation is, and how it can lead to fraud, interoperability failures, and stifling of service innovation.
第2節では、サービスとサービス識別問題を定義することによって開始されます。第3節では、サービスの一部、具体的な例を提供し、なぜ彼らは、識別するために挑戦することができます。セクション4は、サービス識別は、ネットワーク内で利用可能な方法を探ります。次に、第5節では、サービス識別の重要なアーキテクチャの原則について説明します。第6節は、宣言型のサービス呼び出しが何であるかを説明し、どのようにそれが詐欺、相互運用性の障害につながることができ、およびサービスイノベーションの息苦しいです。
Consequently, this document concludes that declarative service identification -- the process by which a user agent inserts a moniker into a message that defines the desired service, separate from explicit and well-defined protocol mechanisms -- is harmful.
ユーザエージェントは、明示的及び明確に定義されたプロトコルメカニズムから分離し、所望のサービスを定義するメッセージにモニカを挿入するプロセス - - 有害な結果として、この文書は、宣言サービス識別と結論します。
Instead of performing declarative service identification, this document recommends derived service identification, and gives several recommendations around it in Section 7:
代わりに、宣言型サービス識別を実行するのは、この文書には、派生サービス識別を推奨し、7節で、その周りにいくつかの推奨事項を示します。
1. The identity of a service should always be derived from the explicit signaling in the protocol messages and other contextual information, and never indicated by the user through a separate identifier placed into the message.
1.サービスの識別は、常にプロトコルメッセージ内の明示的なシグナリングおよび他のコンテキスト情報から導出され、メッセージに入れ別の識別子を介してユーザによって示されたことがないしなければなりません。
2. The process of service identification based on signaling messages must be designed to SIP's negotiative expressiveness, and therefore handle heterogeneity and not assume a fixed set of use cases.
前記シグナリングメッセージに基づいて、サービス識別のプロセスは、SIPのnegotiative表現するように設計され、したがって不均一を処理し、ユースケースの固定セットを想定していないしなければなりません。
3. Presence can help in providing URIs that can be utilized to connect to specific services, thereby creating explicit indications in the signaling that can be used to derive a service identity.
3.存在は、それによってサービスIDを導出するために使用することができるシグナリングに明示的な表示を作成、特定のサービスに接続するために利用することができるURIを提供するのに役立つことができます。
4. Service identities placed into signaling messages for the purposes of caching the service identity are strictly for intra-domain usage.
サービスIDをキャッシュする目的のためにシグナリングメッセージに置か4.サービスのIDは、ドメイン内の使用のために厳密です。
5. Device dispatch should be based on feature tags that map to well-defined SIP extensions and capabilities. Service dispatch should not be based on abstract service identifiers.
5.デバイスの発送は、明確に定義されたSIPの拡張機能や能力にマップ機能タグに基づくべきです。サービスディスパッチは、抽象サービス識別子に基づいてすべきではありません。
The problem of identifying services within SIP is not a new one. The problem has been considered extensively in the context of presence. In particular, the presence data model for SIP [RFC4479] defines the concept of a service as one of the core notions that presence describes. Services are described in Section 3.3 of RFC 4479.
SIP内のサービスを特定の問題は新しいものではありません。問題は存在の文脈で広く考えられてきました。具体的には、SIP [RFC4479]のプレゼンスデータモデルの存在が説明コア概念の一つとして、サービスの概念を定義します。サービスは、RFC 4479のセクション3.3で説明されています。
Essentially, the service is the user-visible use case that is driving the behavior of the user agents and servers in the SIP network. Being user-visible means that there is a difference in user experience between two services that are different. That user experience can be part of the call, or outside of the call. Within a call, the user experience can be based on different media types (an audio call vs. a video chat), different content within a particular media type (stored content, such as a movie or TV session), different devices (a wireless device for "telephony" vs. a PC application for "voice chat"), different user interfaces (a buddy-list view of voice on a PC application vs. a software emulation of a hardphone), different communities that can be accessed (voice chat with other users that have the same voice chat client vs. voice communications with any endpoint on the Public Switched Telephone Network (PSTN)), or different applications that are invoked by the user (manually selecting a Push-To-Talk application from a wireless phone vs. a telephony application). Outside of a call, the difference in user experience can be a billing one (cheaper for one service than another), a notification feature for one and not another (for example, an IM that gets sent whenever a user makes a call), and so on.
本質的に、サービスは、SIPネットワークにおけるユーザエージェントとサーバの動作を駆動しているユーザに見えるユースケースです。ユーザに見えるということは異なっている2つのサービス間でのユーザーエクスペリエンスに差があることを意味します。そのユーザーエクスペリエンスは、コールの呼び出しの一部、または外部にすることができます。コールの中で、ユーザーエクスペリエンスが異なるメディアタイプ（ビデオチャット対オーディオコール）、特定のメディアタイプ（例えば、映画やテレビのセッションとして保存されたコンテンツ、）内の異なるコンテンツを、異なるデバイス（無線に基づくことができますアクセスすることができる「ボイスチャット」のためのPCアプリケーション対「電話」）、別のユーザー・インタフェース（ハードフォンのソフトウェアエミュレーション対PCのアプリケーション上での音声のバディ・リストビュー）、異なるコミュニティのための装置（声公共上の任意のエンドポイントでの音声通信対同じボイスチャットクライアントを持っている他のユーザーとのチャットは、電話網（PSTN））、またはユーザーによって起動される異なるアプリケーションが（手動からプッシュツートークアプリケーションを選択するスイッチテレフォニーアプリケーション対携帯電話）。呼び出しの外では、ユーザーエクスペリエンスの差は1に課金（他より安いのための1つのサービス）、いずれかの通知機能ではなく、他の（ユーザーが呼び出しを行うたび送信される例えば、IM）とすることができ、上のようにします。
In some cases, there is very little difference in the underlying technology that will support two different services, and in other cases, there are big differences. However, for the purposes of this discussion, the key definition is that two services are distinct when there is a perceived difference by the user in the two services.
いくつかの例では、2つの異なるサービスをサポートします基礎となる技術にはほとんど違いがあり、それ以外の場合には、大きな違いがあります。しかし、この議論の目的のために、キー定義は、2つのサービスでは、ユーザによって知覚差があるときに、2つのサービスが異なっているということです。
This leads naturally to the desire to perform service identification. Service identification is defined as the process of:
これは、サービス識別を実行する欲求に自然につながります。サービス識別は、プロセスのように定義されます。
1. determining the underlying service that is driving a particular signaling exchange,
1.特定のシグナリング交換を駆動している根本的なサービスを決定します
3. attaching that moniker to a signaling message (typically a SIP INVITE).
3.（INVITE典型的にSIP）シグナリングメッセージにそのモニカを取り付けます。
Once service identification is performed, the service identifier can then be used for various purposes within the network. Service identification can be done in the endpoints, in which case the UA would insert the moniker directly into the signaling message based on its awareness of the service. Or, it can be done within a server in the network (such as a proxy), based on inspection of the SIP message, or based on hints placed into the message by the user.
サービス識別が行われると、サービス識別子は、ネットワーク内のさまざまな目的に使用することができます。サービス識別は、UAがサービスのその認識に基づいて、シグナリングメッセージに直接モニカを挿入するその場合、エンドポイントで行うことができます。または、それは、SIPメッセージの検査に基づいて、（例えばプロキシとして）ネットワーク内のサーバ内で実行し、ユーザがメッセージに入れヒントに基づくことができます。
When service identification is performed entirely by inspecting the signaling, this is called derived service identification. When it is done based on knowledge possessed only by the invoking user agent, it is called declarative service identification. Declarative service identification can only be done in user agents, by definition.
サービス識別は、シグナリングを検査することによって完全に実行される場合、これは、誘導されたサービスの識別と呼ばれます。それは知識に基づいて行われた場合にのみ起動するユーザエージェントが保有する、それが宣言型のサービス識別と呼ばれています。宣言型サービス識別は、定義により、ユーザーエージェントで行うことができます。
It is very useful to consider several example services, especially ones that appear difficult to differentiate from each other. In cases where it is hard to differentiate, service identification -- and in particular, declarative service identification -- appears highly attractive (and indeed, required).
特に、いくつかの例サービス、相互に区別することは困難で表示されるものを考慮することは非常に便利です。特に、宣言型サービス識別 - - 区別することは困難である場合、サービス識別では非常に魅力的（そして実際に、必要な）が表示されます。
IP Television (IPTV) is the usage of IP networks to access traditional television content, such as movies and shows. SIP can be utilized to establish a session to a media server in a network, which then serves up multimedia content and streams it as an audio and video stream towards the client. Whether SIP is ideal for IPTV is, in itself, a good question. However, such a discussion is outside the scope of this document.
IPテレビ（IPTV）は、IPネットワークの使用量は、映画や番組のように、従来のテレビのコンテンツにアクセスすることです。 SIPは、その後、マルチメディアコンテンツを提供し、クライアントに向けてオーディオ及びビデオストリームとしてストリームネットワークにメディアサーバにセッションを確立するために利用することができます。 SIPは、IPTVのために理想的であるかどうかは、それ自体が、良い質問です。しかし、そのような議論は、この文書の範囲外です。
Consider multimedia conferencing. The user accesses a voice and video conference at a conference server. The user might join in listen-only mode, in which case the user receives audio and video streams, but does not send.
マルチメディア会議を考えてみましょう。ユーザーは、会議サーバでの音声およびビデオ会議にアクセスします。ユーザは、オーディオおよびビデオストリームを受信しますが、送信されません。その場合には聞くだけのモードを、参加するかもしれません。
These two services -- IPTV and listen-only multimedia conferencing -- clearly appear as different services. They have different user experiences and applications. A user is unlikely to ever be confused about whether a session is IPTV or listen-only multimedia conferencing. Indeed, they are likely to have different software applications or endpoints for the two services.
これらの2つのサービス - IPTVと聞くだけのマルチメディア会議は - はっきりなど、さまざまなサービスを見えます。彼らは、異なるユーザー体験とアプリケーションを持っています。ユーザーは、これまでのセッションがIPTVやリッスン専用マルチメディア会議であるかどうかについて混乱になることはほとんどありません。確かに、彼らは2つのサービスのための異なるソフトウェアアプリケーションまたはエンドポイントを持っている可能性があります。
However, these two services look remarkably alike based on the signaling. Both utilize audio and video. Both could utilize the same codecs. Both are unidirectional streams (from a server in the network to the client). Thus, it would appear on the surface that there is no way to differentiate them, based on inspection of the signaling alone.
しかし、これら2つのサービスは、シグナリングをもとに著しく似ています。どちらも、オーディオとビデオを利用しています。どちらも同じコーデックを利用することができます。どちらも、（クライアントへのネットワーク内のサーバからの）単方向ストリームです。このように、それだけでは、シグナリングの検査に基づいて、それらを区別する方法がないことを表面上に現れるでしょう。
Consider an interactive game, played between two users from their mobile devices. The game involves the users sending each other game moves, using a messaging channel, in addition to voice. In another service, users have a voice and IM chat conversation using a buddy-list application on their PC.
インタラクティブなゲームを考えて、自分のモバイルデバイスから二人のユーザー間で演奏。ゲームは、ユーザーが音声に加えて、メッセージングチャネルを使用して、お互いのゲームの動きを送る必要。他のサービスでは、ユーザーが自分のPC上のバディリストのアプリケーションを使用して、音声およびIMチャットの会話を持っています。
In both services, there are two media streams -- audio and messaging. The audio uses the same codecs. Both use the Message Session Relay Protocol (MSRP) [RFC4975]. In both cases, the caller would send an INVITE to the Address of Record (AOR) of the target user. However, these represent fairly different services, in terms of user experience.
オーディオおよびメッセージング - 両方のサービスでは、2つのメディアストリームがあります。オーディオは、同じコーデックを使用しています。双方は、メッセージセッションリレープロトコル（MSRP）[RFC4975]を使用します。どちらの場合も、呼び出し側は、ターゲット・ユーザーのレコード（AOR）のアドレスにINVITEを送信します。しかし、これらは、ユーザーエクスペリエンスの観点では、かなり異なったサービスを表します。
Consider a variation on the example in Section 3.2. In this variation, two users are playing an interactive game between their phones. However, the game itself is set up and controlled using a proprietary mechanism -- not using SIP at all. However, the client application allows the user to chat with their opponent. The chat session is a simple voice session set up between the players.
3.2節の例のバリエーションを考えてみましょう。この変形例では、2人のユーザが自分の携帯電話の間でインタラクティブなゲームをプレイしています。しかし、ゲーム自体を設定し、独自のメカニズムを使用して制御される - すべてでSIPを使用していません。ただし、クライアント・アプリケーションは、ユーザーが自分の相手とチャットすることができます。チャットセッションは、選手の間で設定し、単純な音声セッションです。
Compare this with a basic telephone call between the two users. Both involve a single audio session. Both use the same codecs. They appear to be identical. However, different user experiences are needed. For example, we desire traditional telephony features (such as call forwarding and call screening) to be applied in the telephone service, but not in the gaming chat service.
二人のユーザー間の基本的な電話とこれを比較してください。どちらも、単一のオーディオセッションを伴います。どちらも同じコーデックを使用します。彼らは同じように見えます。しかし、別のユーザー体験が必要とされています。例えば、我々は、（コール転送とコールスクリーニングなど）従来のテレフォニー機能はなく、ゲームチャットサービスでは、電話サービスに適用されることを望みます。
The SIP MESSAGE method [RFC3428] provides a way to send one-shot messages to a particular AOR. This specification is primarily aimed at Short Message Service (SMS)-style messaging, commonly found in wireless phones. Receipt of a MESSAGE request would cause the messaging application on a phone to launch, allowing the user to browse the message history and respond.
SIPのMESSAGEメソッド[RFC3428]は、特定のAORにワンショットメッセージを送信する方法を提供します。この仕様は、主に一般的に無線電話で見つかったショートメッセージサービス（SMS）スタイルのメッセージング、を目的としています。 MESSAGE要求の領収書は、ユーザーがメッセージの履歴を参照し、対応することができ、携帯電話上でのメッセージングアプリケーションが起動する原因となります。
However, a MESSAGE request is sometimes used for the delivery of content to a device for other purposes. For example, some providers use it to deliver configuration updates, such as new phone settings or parameters, or to indicate that a new version of firmware is available. Though not designed for this purpose, the MESSAGE method gets used since, in existing wireless networks, SMS is used for this purpose, and the MESSAGE request is the SIP equivalent of SMS.
しかしながら、MESSAGE要求は、時には他の目的のための装置へのコンテンツの配信のために使用されます。例えば、一部のプロバイダは、このような新しい携帯電話の設定やパラメータなどの設定の更新を、提供するために、またはファームウェアの新しいバージョンが利用可能であることを示すためにそれを使用します。この目的のために設計されていないが、既存の無線ネットワークにおいて、SMSは、この目的のために使用され、MESSAGE要求はSMSのSIPと同等であるが、以来、MESSAGEメソッドが使用されます。
Consequently, the MESSAGE request sent to a phone can be for two different services. One would require invocation of a messaging app, whereas the other would be consumed by the software in the phone, without any user interaction at all.
その結果、携帯電話に送信されたMESSAGEリクエストは、二つの異なるサービスのためにすることができます。他はまったくユーザーとの対話なしに、電話でソフトウェアによって消費されるのに対し、一つは、メッセージングアプリの起動を必要とします。
It is important to understand what the service identity would be utilized for, if known. This section discusses the primary uses. These are application invocation in user agents and the network, Quality of Service authorization, service authorization, accounting and billing, service negotiation, and device dispatch.
知られている場合は、サービスIDは、のために利用されるかを理解することが重要です。このセクションでは、主な用途について説明します。これらは、アプリケーションのユーザー・エージェントでの呼び出しやネットワーク、サービスの認証、サービス認可、会計および課金の品質、サービスネゴシエーション、およびデバイスの派遣です。
In some of the examples above, there were multiple software applications executing on the host. One common way of achieving this is to utilize a common SIP user agent implementation that listens for requests on a single port. When an incoming INVITE or MESSAGE arrives, it must be delivered to the appropriate application software. When each service is bound to a distinct software application, it would seem that the service identity is needed to dispatch the message to the appropriate piece of software. This is shown in Figure 1.
上記の例のいくつかでは、ホスト上で実行する複数のソフトウェアアプリケーションがありました。これを達成するための一般的な方法の1つは、単一のポートでリクエストをリスニングし、共通のSIPユーザエージェントの実装を利用することです。入ってくるINVITEまたはメッセージが到着すると、それは適切なアプリケーションソフトウェアに送達されなければなりません。各サービスは、個別のソフトウェアアプリケーションにバインドされている場合は、サービスのアイデンティティがソフトウェアの適切な部分にメッセージをディスパッチするために必要とされていることと思われます。これは、図1に示されています。
+---------------------------------+
| |
| +-------------+ +-------------+ |
| | UI | | UI | |
| +-------------+ +-------------+ |
| +-------------+ +-------------+ |
| | | | | |
| | Service 1 | | Service 2 | |
| | | | | |
| +-------------+ +-------------+ |
| +-----------------------------+ |
| | | |
| | SIP | |
| | Layer | |
| | | |
| +-----------------------------+ |
| |
+---------------------------------+
Physical Device
物理デバイス
Figure 1
図1
The role of the SIP layer is to parse incoming messages, handle the SIP state machinery for transactions and dialogs, and then dispatch requests to the appropriate service. This software architecture is analogous to the way web servers frequently work. An HTTP server listens on port 80 for requests, and based on the HTTP Request-URI, dispatches the request to a number of disparate applications. The same is happening here. For the example services in Section 3.2, an incoming INVITE for the gaming service would be delivered to the gaming application software. An incoming INVITE for the voice chat service would be delivered to the voice chat application software. The example in Section 3.3 is similar. For the examples in Section 3.4, a MESSAGE request for user-to-user messaging would be delivered to the messaging or SMS app, and a MESSAGE request containing configuration data would be delivered to a configuration update application.
SIP層の役割は、受信メッセージを解析し、トランザクションおよびダイアログのSIP状態機械を処理し、適切なサービスへのリクエストをディスパッチすることです。このソフトウェアアーキテクチャは、Webサーバが頻繁に仕事のやり方に似ています。 HTTPサーバは、要求をポート80でリッスンし、HTTPリクエスト-URIに基づいて、異なるアプリケーションの数にリクエストを送出します。同じことは、ここで起こっています。 3.2節の例のサービスについては、入ってくるゲームサービスのためのINVITEは、ゲームアプリケーションソフトに配信されます。ボイスチャットサービスのためのINVITE着信音声チャットアプリケーションソフトに配信されます。 3.3節の例でも同様です。 3.4節の例では、ユーザ間のメッセージングのメッセージ要求がメッセージングまたはSMSアプリに送達される、および構成データを含むMESSAGE要求は、構成更新アプリケーションに配信されることになります。
Unlike the web, however, in all three use cases, the user initiating communications has (or appears to have -- more below) only a single identifier for the recipient -- their AOR. Consequently, the SIP Request-URI cannot be used for dispatching, as it is identical in all three cases.
ウェブとは異なり、しかし、すべての3つのユースケースで、通信を開始するユーザーが持っている（または持っているように見えます - より下の）受信者のための唯一の単一の識別子 - そのAORを。それは3つ全ての場合において同一であるように、結果として、SIPリクエストURIは、ディスパッチのために使用することができません。
Another usage of a service identifier would be to cause servers in the SIP network to provide additional processing, based on the service. For example, an INVITE issued by a user agent for IPTV would pass through a server that does some kind of content rights management, authorizing whether the user is allowed to access that content. On the other hand, an INVITE issued by a user for multimedia conferencing would pass through a server providing "traditional" telephony features, such as outbound call screening and call recording. It would make no sense for the INVITE associated with IPTV to have outbound call screening and call recording applied, and it would make no sense for the multimedia conferencing INVITE to be processed by the content rights management server. Indeed, in these cases, it's not just an efficiency issue (invoking servers when not needed), but rather, truly incorrect behavior can occur. For example, if an outbound call screening application is set to block outbound calls to everything except for the phone numbers of friends and family, an IPTV request that gets processed by such a server would be blocked (as it's not targeted to the AOR of a friend or family member). This would block a user's attempt to access IPTV services, when that was not the goal at all.
サービス識別子のもう一つの使い方は、SIPネットワーク内のサーバーは、サービスに基づいて、追加的な処理を提供させることであろう。たとえば、ユーザーがそのコンテンツにアクセスすることを許可されているかどうかを認証する、コンテンツ著作権管理のいくつかの種類を行うサーバーを通過するIPTVのためのユーザエージェントによって発行されたINVITE。一方、アウトバウンドコールスクリーニングおよび通話録音などの「伝統的な」テレフォニー機能を提供するサーバーを通過するマルチメディア会議のために、ユーザによって発行されたINVITE。 INVITEアウトバウンドコールスクリーニングとコール録音が適用持つようにIPTVに関連した、およびマルチメディア会議は、コンテンツの著作権管理サーバによって処理されるINVITEのために、それは意味をなさないだろうことは意味をなさないでしょう。実際、これらのケースでは、それだけではない（必要のないとき、サーバを起動する）効率の問題だが、むしろ、本当に不正な動作が発生する可能性があります。アウトバウンドコールスクリーニングアプリケーションは、友人や家族の電話番号を除くすべてのものへのアウトバウンドコールをブロックするように設定されている場合、それはのAORを対象いないとして例えば、このようなサーバーで処理されますIPTVの要求は（ブロックされます友人や家族）。それがすべてで目標ではありませんでしたとき、これは、IPTVサービスにアクセスするユーザの試みをブロックします。
Similarly, a MESSAGE request as described in Section 3.4 might need to pass through a message server for filtering when it is associated with chat, but not when it is associated with a configuration update.
同様に、セクション3.4に記載されるようMESSAGE要求は、それがチャットに関連付けられている場合、フィルタリングのためにメッセージサーバを通過する必要があるかもしれませんが、それは、コンフィギュレーションの更新に関連付けられていない場合。
Consider a filter that gets applied to MESSAGE requests, and that filter runs in a server in the network. The filter operation prevents user Joe from sending messages to user Bob that contain the words "stock" or "purchase", due to some regulations that disallow Joe and Bob from discussing stock trading. However, a MESSAGE for configuration purposes might contain an XML document that uses the token "stock" as some kind of attribute. This configuration update would be discarded by the filtering server, when it should not have been.
MESSAGE要求に適用されますフィルタを検討し、そのフィルタは、ネットワーク内のサーバで実行されます。フィルタ操作は、株取引を議論からジョーとボブを禁止するいくつかの規制のために言葉「株式」または「購入」を、含まれている利用者ボブにメッセージを送信からユーザージョーを防ぐことができます。しかし、設定の目的のためのメッセージは、属性のいくつかの種類としてトークン「株式」を使用してXMLドキュメントが含まれる可能性があります。この構成の更新は、それがされているべきではないときには、フィルタリングサーバによって破棄されるだろう。
The IP network can provide differing levels of Quality of Service (QoS) to IP packets. This service can include guaranteed throughput, latency, or loss characteristics. Typically, the user agent will make some kind of QoS request, either using explicit signaling protocols (such as the Resource ReSerVation Protocol (RSVP) [RFC2205]) or through marking of a Diffserv value in packets. The network will need to make a policy decision based on whether or not these QoS treatments are authorized. One common authorization policy is to check if the user has invoked a service using SIP that they are authorized to invoke, and that this service requires the level of QoS treatment the user has requested.
IPネットワークは、IPパケットにサービスの品質（QoS）の異なるレベルを提供することができます。このサービスは保証されたスループット、遅延、または損失特性を含めることができます。典型的には、ユーザエージェントは、（リソース予約プロトコル（RSVP）[RFC2205]として）またはパケットにDiffservの値のマーキングを介して明示的なシグナリングプロトコルを使用してのいずれかで、QoS要求のいくつかの種類を行います。ネットワークは、これらのQoS処理が許可されているかどうかに基づいて政策決定を行う必要があります。一つの一般的な認可ポリシーは、ユーザーがそれらを呼び出すために許可されているSIPを使用してサービスを呼び出して、このサービスは、ユーザが要求したQoS処理のレベルが必要であることをしているかどうかを確認することです。
For example, consider IPTV and multimedia conferencing as described in Section 3.1. IPTV is a non-real-time service. Consequently, media traffic for IPTV would be authorized for bandwidth guarantees, but not for latency or loss guarantees. On the other hand, multimedia conferencing is in real time. Its traffic would require bandwidth, loss, and latency guarantees from the network.
3.1節で説明したように例えば、IPTVおよびマルチメディア会議を考えます。 IPTVは、非リアルタイムサービスです。その結果、IPTVのためのメディアトラフィックはなく、待ち時間や損失保証のために、帯域保証のために認可されるだろう。一方、マルチメディア会議は、リアルタイムです。そのトラフィックは、ネットワークからの帯域幅、損失、および待ち時間の保証を必要とします。
Consequently, if a user should make an RSVP reservation for a media stream, and ask for latency guarantees for that stream, the network would choose to be able to authorize it if the service was multimedia conferencing, but not if it was IPTV. This would require the server performing the QoS authorization to know the service associated with the INVITE that set up the session.
ユーザがメディアストリームのRSVP予約を行うと、そのストリームのための待ち時間の保証を求める必要がある場合はその結果、ネットワークサービスは、マルチメディア会議であった場合、それを承認することができるように選ぶだろうが、それはIPTVなかった場合。これは、INVITEその設定セッションに関連するサービスを知るためのQoS認証を実行するサーバーが必要になります。
Frequently, a network administrator will want to authorize whether a user is allowed to invoke a particular service. Not all users will be authorized to use all services that are provided. For example, a user may not be authorized to access IPTV services, whereas they are authorized to utilize multimedia processing. A user might not be able to utilize a multiplayer gaming service, whereas they are authorized to utilize voice chat services.
多くの場合、ネットワーク管理者は、ユーザーが特定のサービスを呼び出すことが許可されているかどうかを認可することになるでしょう。すべてのユーザーが提供されているすべてのサービスの使用を許可されるわけではありません。それらは、マルチメディア処理を利用することが許可されているのに対し、例えば、ユーザは、IPTVサービスにアクセスすることを許可されなくてもよいです。それらはボイスチャットサービスを利用することを許可されているのに対し、ユーザーは、マルチプレイヤーゲームのサービスを利用することができない場合があります。
Consequently, when an INVITE arrives at a server in the network, the server will need to determine what the requested service is, so that the server can make an authorization decision.
INVITEネットワーク内のサーバに到着したときに、サーバーが承認決定を行うことができるように、結果的に、サーバは、要求されたサービスが何であるかを決定する必要があります。
Service authorization and accounting/billing go hand in hand. One of the primary reasons for authorizing that a user can utilize a service is that they are being billed differently based on the type of service. Consequently, one of the goals of a service identity is to be able to include it in accounting records, so that the appropriate billing model can be applied.
サービス許可およびアカウンティング/課金は手をつないで行きます。ユーザがサービスを利用できることを認可するための主な理由の1つは、サービスの種類に基づいて異なって課金されていることです。その結果、サービスのアイデンティティの目標の一つは、適切な課金モデルを適用できるように、会計記録に含めることができるようにすることです。
For example, in the case of IPTV, a service provider can bill based on the content (US $5 per movie, perhaps), whereas for multimedia conferencing, they can bill by the minute. This requires the accounting streams to indicate which service was invoked for the particular session.
マルチメディア会議のために、彼らは分単位で課金することができ、一方、例えば、IPTVの場合には、サービスプロバイダは、コンテンツ（おそらく映画あたりUS $ 5）に基づいて法案することができます。これは、特定のセッションのために呼び出されたサービスを示すために、会計・ストリームを必要とします。
In some cases, when the caller initiates a session, they don't actually know which service will be utilized. Rather, they might choose to offer up all of the services they have available to the called party, and then let the called party decide, or let the system make a decision based on overlapping service capabilities.
いくつかのケースでは、呼び出し側がセッションを開始するとき、彼らは実際に利用されるサービスかわかりません。むしろ、彼らはと呼ばれるパーティーに利用可能なサービスのすべてを提供することを選択するかもしれませんが、その後、着信側が決定させる、またはシステムがサービス機能の重複に基づいて意思決定を作ってみよう。
As an example, a user can do both the game and the voice chat service described in Section 3.2. The user initiates a session to a target AOR, but the devices used by the target can only support voice chat. The called device returns, in its call acceptance, an indication that only voice chat can be used. Consequently, voice chat gets utilized for the session.
一例として、ユーザは、ゲームと3.2節で説明したボイスチャットサービスの両方を行うことができます。ユーザーは、ターゲット・AORへのセッションを開始しますが、ターゲットが使用するデバイスはボイスチャットをサポートすることができます。呼ばれるデバイスが戻ると、その呼受付で、表示のみボイスチャットを使用することができます。そのため、ボイスチャットは、セッションのために利用されます。
When a user has multiple devices, each with varying capabilities in terms of service, it is useful to dispatch an incoming request to the right device based on whether the device can support the service that has been requested.
ユーザが複数のデバイスを有する場合に、サービスの点で機能が変化する毎に、デバイスが要求されたサービスをサポートできるかどうかに基づいて、右のデバイスへの着信要求をディスパッチするのに有用です。
For example, if a user initiates a gaming session with voice chat, and the target user has two devices -- one that can support the gaming service, and another that cannot -- the INVITE should be dispatched to the device that supports the gaming session.
例えば、ユーザは音声チャットとゲームセッションを開始する場合、ターゲットユーザーは、2つのデバイスがある - ゲームサービスをサポートできるものを、そして他のことができない - INVITEは、ゲームセッションをサポートするデバイスに派遣する必要があります。
In this section, we describe several key principles of service identification:
このセクションでは、サービス識別のいくつかの重要な原則を説明します。
3. Declarative service identification is an example of "Do What I Mean" (DWIM)
3.宣言サービス識別は、「私が何を意味するかですか」の一例である（DWIM）
Declarative service identification -- the addition of a service identifier by clients in order to inform other entities of what the service is -- is a very compelling solution to solving the use cases described above. It provides a clear way for each of the use cases to be differentiated. On the other hand, derived service identification appears "hard", since the signaling appears to be the same for these different services.
宣言型サービス識別 - サービスが何であるかの他のエンティティに通知するために、クライアントによるサービス識別子の追加は、 - 上記のユースケースを解決するための非常に魅力的なソリューションです。これは、ユースケースのそれぞれが区別されるための明確な方法を提供します。シグナリングはこれらの異なるサービスに同じように見えるので、一方、派生サービス識別は、「ハード」と表示されます。
Declarative service identification misses a key point, which cannot be stressed enough, and which represents the core architectural principle to be understood here:
宣言型のサービス識別が十分に強調することができないキーポイントを、ミス、及びここで理解すべきコアアーキテクチャ原理を表します。
A service is the byproduct of the signaling and the context around it (the user profile, time of day, and so on) -- the effects of the signaling message once it is launched into the network. The service identity is therefore always derivable from the signaling and its context without additional identifiers. In other words, derived service identification is always possible when signaling is being properly handled.
それがネットワークに投入されると、シグナリングメッセージの影響 - サービスは、シグナリングとその周辺のコンテキスト（ユーザー・プロファイル、一日の時間など）の副産物です。サービスIDは、追加の識別子なしでシグナリングとその文脈から誘導常にゆえです。シグナリングは、適切に処理されているとき換言すれば、誘導されたサービスの識別は常に可能です。
When a user sends an INVITE request to the network and targets that request at an IPTV server, and includes the Session Description Protocol (SDP) for audio and video streaming, the *result* of sending such an INVITE is that an IPTV session occurs. The entire purpose of the INVITE is to establish such a session, and therefore, invoke the service. Thus, a service is not something that is different from the rest of the signaling message. A service is what the user gets after the network and other user agents have processed a signaling message.
ユーザーがIPTVサーバに要求し、ネットワークとターゲットへのINVITEリクエストを送信し、オーディオとビデオストリーミング、*などINVITE送信の*の結果のためのセッション記述プロトコル（SDP）を含む場合はIPTVセッションが発生することです。 INVITEの全体の目的は、そのようなセッションを確立することであり、したがって、サービスを呼び出します。したがって、サービスは、シグナリングメッセージの残りの部分と異なるものではありません。サービスは、ネットワークやその他のユーザーエージェントは、シグナリングメッセージを処理した後、ユーザーが得るものです。
It may seem that delayed offers (SIP INVITE requests that lack SDP) make it impossible to perform derived service identification. After all, in some of the cases above, the differentiation was done using the SDP in the request. What if it's not there? The answer is simple -- if it's not there, and the SDP is being offered by the called party, you cannot in fact know the service at the time of the INVITE. That's the whole point of delayed offer -- to give the called party the chance to offer up what it wants for the session. In cases where service identification is needed at request time, delayed offer cannot be used.
遅延申し出が（SIPは、SDPに欠けるINVITE要求）それが不可能派生サービス識別を行うために作ることに思えるかもしれません。結局、上記の場合のいくつかでは、分化は要求にSDPを用いて行きました。何それがないのですか？答えは簡単です - それはありません、とSDPは、被呼者によって提供されている場合は、実際には、INVITEの時点でサービスを知ることができません。これは、遅延オファーの全体のポイントだ - と呼ばれるパーティにそれがセッションのために何を望んアップを提供する機会を得ました。サービス識別は、要求時に必要とされる場合には、遅れたオファーは使用できません。
This principle is a natural conclusion of the previous assertion. If a service is the byproduct of signaling, how can a user have different experiences and different services when the signaling message is the same? They cannot.
この原則は、以前の主張の自然な結論です。サービスは、シグナリングの副産物である場合には、シグナリングメッセージが同じであれば、どのようにユーザーが別の経験と異なるサービスを持つことができますか？彼らがすることはできません。
But how can that be? From the examples in Section 3, it would seem that there are services that are different, but have identical signaling. If we hold true to the assertion, there is in fact only one logical conclusion:
しかし、どのようにそれをすることができますか？第3節での例から、異なっているサービスがあるように見えるが、同じシグナリングを持っているでしょう。私たちは主張に当てはまる場合は、唯一の論理的な結論は、実際にあります：
If two services are different, but their signaling appears to be the same, it is because one or more of the following is true:
2つのサービスが異なっているが、そのシグナル伝達は同じように見える場合は、次の1つ以上が真であるので、それは次のとおりです。
2. something has been implied from the signaling, when in fact it should have been signaled explicitly
2.実際にはそれが明示的にシグナリングされている必要があるときに何かが、シグナリングから暗示されています
3. the signaling mechanism should be changed so that there is, in fact, something that is different
実際には、そこにあるように3シグナリングメカニズムは、別の何かを変更する必要があります
To illustrate this, let us take each of the example services in Section 3 and investigate whether there is, or should be, something different in the signaling in each case.
これを説明するために、私たちは第3節で例の各サービスを取り、そこにある、または、それぞれの場合のシグナリングにおける別の何かにするかどうかを調べてみましょう。
IPTV vs. Multimedia Conferencing: The two services described in Section 3.1 appear to have identical signaling. They both involve audio and video streams, both of which are unidirectional. Both might utilize the same codecs. However, there is another important difference in the signaling -- the target URI. In the case of IPTV, the request is targeted at a media server or to a particular piece of content to be viewed. In the case of multimedia conferencing, the target is a conference server. The administrator of the domain can therefore examine the Request-URI and figure out whether it is targeted for a conference server or a content server, and use that to derive the service associated with the request.
マルチメディア会議対IPTV：3.1節で説明する2つのサービスは、同一のシグナルを持っているように見えます。どちらも単方向でどちらも、オーディオおよびビデオストリームを伴います。どちらも同じコーデックを利用することがあります。ターゲットURI - しかし、シグナル伝達においてもう一つの重要な違いがあります。 IPTVの場合には、要求は、メディアサーバーで、または視聴するコンテンツの特定の部分に標的化されます。マルチメディア会議の場合は、ターゲットは、会議サーバです。ドメインの管理者は、そのためのRequest-URIを調べ、それが会議サーバやコンテンツサーバを対象としているかどうかを把握し、その要求に関連するサービスを導出するためにそれを使用することができます。
Gaming vs. Voice Chat: Though both sessions involve MSRP and voice, and both are targeted to the same AOR of the called user, there is a difference. The MSRP messages for the gaming session carry content that is game specific, whereas the MSRP messages for the voice chat are just regular text, meant for rendering to a user. Thus, the MSRP session in the SDP will indicate the specific content type that MSRP is carrying, and this type will differ in both cases. Even if the game moves look like text, since they are being consumed by an automata, there is an underlying schema that dictates their content, and therefore, this schema represents the actual content type that should be signaled.
ボイスチャット対賭博：両方のセッションがMSRPと声を伴い、そして両方が呼ばれ、ユーザーの同じAORを対象としているが、違いがあります。音声チャットのためのMSRPメッセージがユーザーにレンダリングするためのものだけで、通常のテキスト、あるのに対し、ゲーム固有のゲームセッションキャリーコンテンツのためのMSRPメッセージ。このように、SDPにおけるMSRPセッションがMSRPが担持されている特定のコンテンツタイプを示すであろう、そしてこのタイプは、両方の場合で異なります。ゲームが動くが、テキストのように見える場合でも、彼らはオートマトンによって消費されているので、その内容を規定する基本的なスキーマがあり、そのため、このスキーマが通知されなければならない実際のコンテンツの種類を表します。
Gaming vs. Voice Chat #2: In this case, both sessions involve only voice, and both are targeted at the same AOR. Indeed, there truly is nothing different -- if indeed the signaling works this way. However, there is an alternative mechanism for performing the signaling. For the gaming session, the proprietary protocol can be used to exchange a URI that can be used to identify the voice chat function on the phone that is associated with the game (for example, a Globally Routable User Agent URI (GRUU) can be used [RFC5627]). Indeed, the gaming chat is not targeting the USER -- it's targeting the gaming instance on the phone. Thus, if a special GRUU is used for the gaming chat, this makes the signaling different between these two services.
ボイスチャットの＃2対ゲームは：この場合、両方のセッションは、音声のみを伴い、そして両方が同じAORをターゲットにしています。実際、本当に違うものは何もない - 確かに、シグナリングがこのように動作するかどうか。しかしながら、シグナリングを行うための別のメカニズムがあります。ゲームセッションのために、独自のプロトコルは、例えば、グローバルにルーティング可能なユーザエージェントURI（GRUU）を使用することができる（ゲームに関連付けられている電話のボイスチャット機能を識別するために使用できるURIを交換するために使用することができます[RFC5627]）。確かに、ゲームチャットはユーザーをターゲットにされていない - それは電話でゲームインスタンスをターゲットです。特別GRUUは、ゲームチャットのために使用されている場合はこのように、これは、これら2つのサービスの間で異なる信号を作ります。
Configuration vs. Pager Messaging: Just as in the case of gaming vs. voice chat, the content type of the messages differentiates the service that occurs as a consequence of the messages.
ポケットベルメッセージ対の構成：ちょうど音声チャット対ゲームの場合のように、メッセージのコンテンツタイプは、メッセージの結果として発生するサービスを区別します。
"Do What I Mean", abbreviated as DWIM, is a concept in computer science. It is sometimes used to describe a function that tries to intelligently guess at what the user intended. It is in contrast to "Do What I Say", or DWIS, which describes a function that behaves concretely based on the inputs provided. Systems built on the DWIM concept can have unexpected behaviors, because they are driven by unstated rules.
「私は何を意味するか」、DWIMと略記、コンピュータサイエンスの概念です。時々賢く利用者が意図したもので推測しようと機能を記述するために使用されます。それは「私の言うことですか」とは対照的、あるいは具体的に提供する入力に基づいて動作します機能を説明しDWIS、です。それらは暗黙のルールによって駆動されるので、DWIMの概念上に構築されたシステムは、予期しない動作を持つことができます。
Declarative service identification is an example of DWIM. The service identifier has no well-defined impact on the state machinery or protocols in the system; it has various side effects based on an assumption of what is meant by the service identifier. Derived service identification, on the other hand, is an expression of the principle of DWIS -- the behavior of the system is based entirely on the specifics of the protocol and are well defined by the protocol specification. The service identifier is just a shorthand for summarizing things that are well defined by signaling.
宣言型サービス識別はDWIMの一例です。サービス識別子は、システム内の状態機械またはプロトコルには、明確に定義された影響を有します。それは、サービス識別子が何を意味するかの仮定に基づいて、様々な副作用があります。誘導されたサービスの識別が、一方、DWISの原理の表現である - システムの動作は、プロトコルの仕様に完全に基づいており、ウェルプロトコル仕様で定義されています。サービス識別子はちょうど良く、シグナリングによって定義されたものを要約するための省略形です。
As a litmus test to differentiate the two cases, consider the following question. If a request contained a service identifier, and that request were processed by a domain that didn't understand the concept of service identifiers at all, would the request be rejected if that service were not supported, or would it complete but do the wrong thing? If it is the latter case, it's DWIM. If it's the former, it's DWIS.
2例を区別するためのリトマス試験として、以下の質問を検討してください。リクエストは、サービス識別子を含んでおり、その要求は、そのサービスがサポートされていなかった場合、要求は拒否される、すべてのサービス識別子の概念を理解していないドメインで処理された、またはそれは完全なだろうが、間違ったことをすれば？それは後者の場合であれば、それはDWIMです。それはかつてのなら、それがdwisです。
Because a declarative service identifier is, by definition, inside of the signaling message, and because the signaling itself completely defines the behavior of the service, another natural conclusion is that a declarative service identifier is redundant with the signaling itself. It says nothing that could not or should not otherwise be derived from examination of the signaling.
宣言型サービス識別子は、定義によって、シグナリングメッセージ内であり、およびシグナリング自体が完全にサービスの動作を定義するため、別の天然の結論は、宣言サービス識別子がシグナリング自体と冗長であるということである。ためこれは、またはその他のシグナリングの調査から導き出さすべきではないことができませんでした何も言います。
In the IPTV example and in the second gaming example, it was ultimately the Request-URI that was (or should be) different between the two services. This is important. In many cases where services appear the same, it is because the resource that is being targeted is not, in fact, the user. Rather, it is a resource that is linked with the user. This resource might be an instance of a software application on the particular device of a user, or a resource in the network that acts on behalf of the user.
IPTVの例では第二のゲームの例では、最終的に2つのサービスの間で異なっていた（またはあるべきである）のRequest-URIでした。これは重要。サービスが同じに見える多くの場合、それが目標とされているリソースはないので、実際には、ユーザーです。むしろ、それはユーザーにリンクされているリソースです。このリソースは、ユーザーの特定のデバイス、またはユーザに代わって動作するネットワーク内のリソース上のソフトウェアアプリケーションのインスタンスであるかもしれません。
The Request-URI is an infinitely large namespace for identifying these resources. It is an ideal mechanism for providing differentiation when there would otherwise be none.
Request-URIがこれらのリソースを識別するための無限大のネームスペースです。これは、そうでない場合は何もないでしょう分化を提供するための理想的なメカニズムです。
Returning again to the example in Section 3.3, we can see that it does make more sense to target the gaming chat session at a software instance on the user's phone, rather than at the user themselves. The gaming chat session should really only go to the phone on which the user is playing the game. The software instance does indeed live only on that phone, whereas the user themselves can be contacted in many ways. We don't want telephony features invoked for the gaming chat session, because those features only make sense when someone is trying to communicate with the USER. When someone is trying to communicate with a software instance that acts on behalf of the user, a different set of rules apply, since the target of the request is completely different.
3.3節の例に再び戻ると、我々はそれがむしろ利用者自身よりも、ユーザーの携帯電話のソフトウェアのインスタンスでゲームチャットセッションをターゲットにするより多くの意味を成してないことがわかります。ユーザーがゲームをプレイしているゲームのチャットセッションは本当に唯一の携帯電話に行く必要があります。ユーザー自身が多くの方法で接触させることができるのに対し、ソフトウェアのインスタンスは、実際に、その電話でのみ生きるん。誰かがUSERと通信しようとしたとき、これらの機能はのみ意味をなすので、我々は、ゲームのチャットセッションのために呼び出されたテレフォニー機能を望んでいません。誰かがユーザーに代わって動作するソフトウェアのインスタンスと通信しようとしている場合は、要求のターゲットは完全に異なっているので、ルールの異なるセットは、適用されます。
Based on these principles, several perils of declarative service identification can be described. They are:
これらの原理に基づいて、宣言型サービス識別のいくつかの危険を記述することができます。彼らです：
Declarative service identification can lead to fraud. If a provider uses the service identifier for billing and accounting purposes, or for authorization purposes, it opens an avenue for attack. The user can construct the signaling message so that its actual effect (which is the service the user will receive), is what the user desires, but the user places a service identifier into the request (which is what is used for billing and authorization) that identifies a cheaper service, or one that the user is not authorized to receive. In such a case, the user will receive service, and not be billed properly for it.
宣言型サービス識別は、詐欺につながることができます。プロバイダは、課金および会計の目的のためにサービス識別子を使用している場合、または認証目的のために、それは攻撃のために道を開きます。 （ユーザーが受信するサービスである）は、その実際の効果は、ユーザが望むものであるが、ユーザは（課金および許可のために使用されるものである）要求にサービス識別子を配置するように、ユーザは、シグナリングメッセージを構築することができますそれは安価なサービス、またはユーザーが受信を許可されていないものを識別します。このような場合、ユーザはサービスを受けるだろうし、それに対して適切に請求されることはありません。
If, however, the domain administrator derived the service identifier from the signaling itself (derived service identification), the user cannot lie. If they did lie, they wouldn't get the desired service.
しかし、ドメイン管理者は、それ自体をシグナリング（派生サービス識別）からサービス識別子を派生した場合、ユーザーが存在することができません。彼らは嘘をした場合は、それらが所望のサービスを得ないでしょう。
Consider the example of IPTV vs. multimedia conferencing. If multimedia conferencing is cheaper, the user could send an INVITE for an IPTV session, but include a service identifier that indicates multimedia conferencing. The user gets the service associated with IPTV, but at the cost of multimedia conferencing.
マルチメディア会議対IPTVの例を考えてみましょう。マルチメディア会議が安価であれば、ユーザーは、IPTVセッションのためにINVITEを送るが、マルチメディア会議を示すサービス識別子を含めることができます。ユーザーは、IPTVに関連するサービスを取得しますが、マルチメディア会議のコストで。
This same principle shows up in other places -- for example, in the identification of an emergency services call [ECRIT-FRAMEWORK]. It is desirable to give emergency services calls special treatment, such as being free and authorized even when the user cannot otherwise make calls, and to give them priority. If emergency calls were indicated through something other than the target of the call being an emergency services URN [RFC5031], it would open an avenue for fraud. The user could place any desired URI in the request-URI, and indicate separately, through a declarative identifier, that the call is an emergency services call. This would then get special treatment but of course would get routed to the target URI. The only way to prevent this fraud is to consider an emergency call as any call whose target is an emergency services URN. Thus, the service identification here is based on the target of the request. When the target is an emergency services URN, the request can get special treatment. The user cannot lie, since there is no way to separately indicate that this is an emergency call, besides targeting it to an emergency URN.
これと同じ原理が他の場所に表示 - 例えば、緊急サービスの識別に[ECRIT-FRAMEWORK]を呼び出します。このような自由で、ユーザがそれ以外の場合は電話をかけることができず、それらに優先順位を与える場合であっても許可さなどの特別な治療を呼び出し、緊急サービスを提供することが望ましいです。緊急コールは、緊急サービスURN [RFC5031]が呼び出しのターゲット以外の何かによって示された場合、それは詐欺のために道を開くだろう。ユーザーがリクエストURIに任意のURIを置き、コールが緊急サービスコールであることを、宣言型識別子を通じて、個別に示している可能性があり。そして、これは特別な治療を受けるだろうが、当然のことながら、ターゲットURIにルーティングさになるだろう。この詐欺を防止するための唯一の方法は、目標緊急サービスURNである任意の呼び出しなどの緊急コールを考慮することです。したがって、ここでのサービス識別は、要求の対象に基づいています。ターゲットは、緊急サービスURNである場合には、要求は、特別な治療を受けることができます。別にこれは緊急URNにそれをターゲット以外にも、緊急コールであることを示す方法がないため、ユーザーは、嘘はできません。
How can declarative service identification cause loss of interoperability? When an identifier is used to drive functionality -- such as dispatch on the phones, in the network, or QoS authorization -- it means that the wrong thing can happen when this field is not set properly. Consider a user in domain 1, calling a user in domain 2. Domain 1 provides the user with a service they call "voice chat", which utilizes voice and IM for real-time conversation, driven off of a buddy-list application on a PC. Domain 2 provides their users with a service they call "text telephony", which is a voice service on a wireless device that also allows the user to send text messages. Consider the case where domain 1 and domain 2 both have their user agents insert a service identifier into the request, and then use that to perform QoS authorization, accounting, and invocation of applications in the network and in the device. The user in domain 1 calls the user in domain 2, and inserts the identifier "Voice Chat" into the INVITE. When this arrives at the server in domain 2, the service identifier is unknown. Consequently, the request does not get the proper QoS treatment, even if the call itself will succeed.
どのように相互運用性のサービス識別原因の損失を、宣言することができますか？そのようなネットワークでの電話の発信、またはQoSの承認など - - 識別子が機能を駆動するために使用される場合には、このフィールドが正しく設定されていない場合、間違った事は起こることができることを意味します。 2.ドメイン1は、上でバディリストアプリケーションのオフ駆動リアルタイムの会話の音声やIMを利用して、彼らは、「ボイスチャット」と呼ぶサービス、、をユーザに提供し、ドメイン内のユーザーを呼び出して、ドメイン1内のユーザーを考えてみましょうPC。ドメイン2は、ユーザーがテキストメッセージを送信することを可能にするワイヤレスデバイス上の音声サービスである彼らは、「テキスト電話」と呼んサービス、と彼らのユーザーに提供します。ドメイン1とドメイン2の両方が彼らのユーザーエージェントがリクエストにサービス識別子を挿入し、QoSの認証、アカウンティング、およびネットワーク上のデバイスでのアプリケーションの呼び出しを実行するためにそれを使用していた場合を考えてみましょう。ドメイン1内のユーザーは、ドメイン2内のユーザーを呼び出し、INVITEに識別子「ボイスチャット」を挿入します。これは、ドメイン2でサーバに到着すると、サービス識別子は不明です。その結果、要求は、コール自体が成功する場合でも、適切なQoS処理を取得していません。
If, on the other hand, derived service identification were used, the service identifier could be removed by domain 2, and then recomputed based on the signaling to match its own notion of services. In this case, domain 2 could derive the "text telephony" identifier, and the request completes successfully.
一方、誘導されたサービス識別を使用した場合、サービス識別子は、ドメイン2によって除去し、次いでサービスの独自の概念と一致するシグナルに基づいて再計算することができます。この場合、ドメイン2は、「テキストテレフォニー」の識別子を導き出すことができ、かつ要求が正常に完了します。
Declarative service identification, used between domains, causes interoperability failures unless all interconnected domains agree on exactly the same set of services and how to name them. Of course, lack of service identifiers does not guarantee service interoperability. However, SIP was built with rich tools for negotiation of capabilities at a finely granular level. One user agent can make a call using audio and video, but if the receiving UA only supports audio, SIP allows both sides to negotiate down to the lowest common denominator. Thus, communication is still provided. As another example, if one agent initiates a Push-To-Talk session (which is audio with a companion floor control mechanism), and the other side only did regular audio, SIP would be able to negotiate back down to a regular voice call. As another example, if a calling user agent is running a high-definition video conferencing endpoint, and the called user agent supports just a regular video endpoint, the codecs themselves can negotiate downward to a lower rate, picture size, and so on. Thus, interoperability is achieved. Interestingly, the final "service" may no longer be well characterized by the service identifier that would have been placed in the original INVITE. For example, in this case, if the original INVITE from the caller had contained the service identifier "hi-fi video", but the video gets negotiated down to a lower rate and picture size, the service identifier is no longer really appropriate. That is why services need to be derived by signaling -- because the signaling itself provides negotiation and interoperability between different domains.
すべての相互接続されたドメインがまったく同じサービスのセットとどのようにそれらに名前を付けることに同意しない限り、宣言型のサービス識別は、ドメイン間で使用され、相互運用性の障害の原因となります。もちろん、サービス識別子の欠如は、サービスの相互運用性を保証するものではありません。しかし、SIPは細かく細かいレベルでの能力の交渉のための豊富なツールで構築されました。一つのユーザエージェントは、オーディオとビデオを使って電話をかけることができますが、受信UAは、音声のみサポートしている場合、SIPは、両側が最小公分母にダウン交渉することができます。したがって、通信はまだ提供されています。別の例として、一つの薬剤は、（コンパニオンフロア制御機構を備えたオーディオである）プッシュツートークセッションを開始する場合、および他の側面だけで通常のオーディオをした、SIPは、通常の音声通話まで戻って交渉することができるだろう。呼び出しユーザエージェントは、高精細ビデオ会議エンドポイントを実行している、と呼ばれるユーザーエージェントは、普通のビデオエンドポイントをサポートしている場合、別の例として、コーデック自体はそれほどに低いレート、画像サイズ、およびに下向きに交渉することができます。このように、相互運用性が実現されます。興味深いことに、最終的な「サービス」は、もはや十分INVITE元に置かれていたサービス識別子によって特徴付けすることはできません。元の発信者からのINVITEはサービス識別子「ハイファイビデオ」を含んでいたが、映像はより低いレートと画像サイズにまで交渉してしまった場合たとえば、この場合には、サービス識別子は、もはや本当に適切ではありません。シグナリング自体は、異なるドメイン間での交渉との相互運用性を提供するため、 - サービスは、シグナリングによって導出する必要がある理由です。
This illustrates another key aspect of the interoperability problem. Declarative service identification will result in inconsistencies between its service identifiers and the results of any SIP negotiation that might otherwise be applied in the session.
これは、相互運用性の問題のもう一つの重要な側面を示しています。宣言型サービス識別は、そのサービス識別子とそれ以外のセッションに適用される可能性があります任意のSIP交渉の結果との間に矛盾が発生します。
When a service identifier becomes something that both proxies and the user agent need to understand in order to properly treat a request (which is the case for declarative service identification), it becomes equivalent to including a token in the Proxy-Require and Require header fields of every single SIP request. The very reason that [RFC4485] frowns upon usage of Require and certainly Proxy-Require is the huge impact on interoperability it causes. It is for this same reason that declarative service identification needs to be avoided.
サービス識別子は、両方のプロキシとユーザエージェントが適切に（宣言サービス識別のためのケースである）要求を処理するために理解する必要があるものになると、プロキシ要求と要求ヘッダフィールドのトークンを含むと等価となりますすべての単一のSIPリクエストの。必要と確かにプロキシ要求の使用時に[RFC4485]しかめ面、非常に理由は、それが原因との相互運用性に大きな影響です。これは、宣言型のサービス識別を回避する必要があることを、これと同じ理由です。
The probability that any two service providers end up with the same set of services, and give those services the same names, becomes smaller and smaller as the number of providers grow. Indeed, it would almost certainly require a centralized authority to identify what the services are, how they work, and what they are named. This, in turn, leads to a requirement for complete homogeneity in order to facilitate interconnection. Two providers cannot usefully interconnect unless they agree on the set of services they are offering to their customers and each do the same thing. This is because each provider has become dependent on inclusion of the proper service identifier in the request, in order for the overall treatment of the request to proceed correctly. This is, in a very real sense, anathema to the entire notion of SIP, which is built on the idea that heterogeneous domains can interconnect and still get interoperability.
プロバイダの数が増えるように、任意の2つのサービスプロバイダがサービスの同じセットで終わる、およびそれらのサービスに同じ名前を与える確率は、ますます小さくなっています。確かに、それはほぼ確実に彼らがどのように動作するか、サービスが何であるかを識別するための集中権限が必要になり、彼らの名前は何。これは、順番に、相互接続を容易にするために、完全な均質性のための要件につながります。彼らは彼らの顧客に提供している、それぞれが同じことを行うサービスのセットに同意しない限り、2つのプロバイダが有効に相互接続することはできません。各プロバイダが正しく進めるための要求の全体的な治療のためには、リクエストで適切なサービス識別子を含めることに依存するようになったためです。これは、本当の意味で、異種ドメインは相互接続し、まだ相互運用性を得ることができるという考えに基づいて構築されたSIPの全体の概念、に忌み嫌わです。
Declarative service identification leads to a requirement for homogeneity in service definitions across providers that interconnect, ruining the very service heterogeneity that SIP was meant to bring.
宣言型サービス識別は、相互接続、SIPを持参することを意図したことは非常にサービスの不均一性を台無しプロバイダ間でのサービス定義の均一性のための要件につながります。
Indeed, Metcalfe's Law says that the value of a network grows with the square of the number of participants. As a consequence of this, once a bunch of large domains did get together, agree on a set of services, and then agree on a set of well-known identifiers for those services, it would force other providers to also deploy the same services, in order to obtain the value that interconnection brings. This, in turn, will stifle innovation, and quickly force the set of services in SIP to become fixed and never expand beyond the ones initially agreed upon. This, too, is anathema to the very framework on which SIP is built, and defeats much of the purpose of why providers have chosen to deploy SIP in their own networks.
確かに、メトカーフの法則は、ネットワークの価値は、参加者の数の二乗に比例して増大することを言います。 、それはまた、同じサービスを展開するために、他のプロバイダを強制する、大規模なドメインの束を一緒に手に入れた後、この結果として、サービスのセットに同意した後、それらのサービスのためによく知られている識別子のセットに同意相互接続がもたらす価値を得るためです。これは、順番に、技術革新を抑圧し、かつ迅速に固定となり、当初合意されたものを超えて拡大しないようにSIPに一連のサービスを強制します。これは、あまりにも、SIPが構築されている非常にフレームワークに忌み嫌わで、プロバイダが自分のネットワークにSIPを配備することを選択した理由の目的の多くを破ります。
Consider the following example. Several providers get together and standardize on a bunch of service identifiers. One of these uses audio and video (say, "multimedia conversation"). This service is successful and is widely utilized. Endpoints look for this identifier to dispatch calls to the right software applications, and the network looks for it to invoke features, perform accounting, and provide QoS. A new provider gets the idea for a new service (say, "avatar-enhanced multimedia conversation"). In this service, there is audio and video, but there is a third stream, which renders an avatar. A caller can press buttons on their phone, to cause the avatar on the other person's device to show emotion, make noise, and so on. This is similar to the way emoticons are used today in IM. This service is enabled by adding a third media stream (and consequently, a third m-line) to the SDP.
次の例を考えてみましょう。いくつかのプロバイダは、一緒に取得し、サービス識別子の束を標準化。これらの一つは、オーディオおよびビデオ（たとえば、「マルチメディア会話」）を使用しています。このサービスは成功し、広く利用されています。エンドポイントは右のソフトウェア・アプリケーションへの呼び出しをディスパッチするには、この識別子を探し、そしてそれは、機能を呼び出すアカウンティングを実行し、QoSを提供するためのネットワークを検索します。新しいプロバイダは、新たなサービス（たとえば、「アバター強化マルチメディア会話」）のためのアイデアを取得します。このサービスでは、オーディオとビデオがありますが、アバターをレンダリングする第三の流れは、そこにあります。呼び出し側はこれに、感情を示して音を立てる、とするために、他の人のデバイス上のアバターを引き起こすために、自分の携帯電話のボタンを押すことができます。これは、IMで今日使用されている方法の顔文字に似ています。このサービスは、SDPに（その結果と、第Mライン）第三のメディアストリームを追加することによって有効になっています。
Normally, this service would be backwards-compatible with a regular audio-video endpoint, which would just reject the third media stream. However, because a large network has been deployed that is expecting to see the token, "multimedia conversation" and its associated audio+ video service, it is nearly impossible for the new provider to roll out this new service. If they did, it would fail completely, or partially fail, when their users call users in other provider domains.
通常、このサービスは、ちょうど第三メディアストリームを拒否しており、通常のオーディオ・ビデオエンドポイントとの後方互換性だろう。大規模なネットワークは、トークン、「マルチメディア会話」とその関連オーディオ+ビデオサービスを見ることが期待されている展開されているので、新しいプロバイダは、この新しいサービスを展開するためにしかし、それはほとんど不可能です。彼らがした場合、それは彼らのユーザーが、他のプロバイダのドメイン内のユーザーを呼び出すときに、完全に失敗、または部分的に失敗していました。
From these principles, several recommendations can be made.
これらの原則から、いくつかの提言を行うことができます。
Derived service identification -- where an identifier for a service is obtained by inspection of the signaling and of other contextual data (such as subscriber profile) -- is reasonable, and when done properly, does not lead to the perils described above. However, declarative service identification -- where user agents indicate what the service is, separate from the rest of the signaling -- leads to the perils described above.
誘導されたサービス識別 - サービスの識別子がシグナリングの及び（例えば、加入者プロファイルなどの）他のコンテキストデータの検査によって得られた - 合理的であり、適切に行う場合、上述した危険につながりません。しかし、宣言型サービス識別 - ユーザエージェントは、シグナリングの残りの部分から分離し、サービスが何であるかを示す - 上述の危険をもたらします。
If it appears that the signaling currently defined in standards is not sufficient to identify the service, it may be due to lack of sufficient signaling to convey what is needed, or may be because request URIs should be used for differentiation and they are not being used. By applying the litmus tests described in Section 5.3, network designers can determine whether or not the system is attempting to perform declarative service identification.
現在の規格で定義されたシグナリングがサービスを識別するのに十分ではない、それは必要とされているものを伝えるために十分なシグナルの欠如が原因である可能性があり、またはリクエストURIは差別化のために使用すべきであると彼らが使用されていないためであり得ることを表示された場合。セクション5.3で説明リトマス試験を適用することにより、ネットワーク設計者は、システムが宣言サービス識別を実行しようとしているか否かを判断することができます。
One of SIP's key strengths is its ability to negotiate a common view of a session between participants. This means that the service that is ultimately received can vary wildly, depending on the types of endpoints in the call and their capabilities. Indeed, this fact becomes even more evident when calls are set up between domains.
SIPの強みの一つは、参加者間のセッションの共通のビューを交渉する能力です。これは、最終的に受信されたサービスは、コールとその機能内のエンドポイントの種類に応じて、乱暴に変わることを意味します。コールは、ドメイン間に設定されている場合確かに、この事実はさらに明らかになる。
As such, when performing derived service identification, domains should be aware that sessions may arrive from different networks and different endpoints. Consequently, the service identification algorithm must be complete -- meaning it computes the best answer for any possible signaling message that might be received and any session that might be set up.
誘導されたサービスの識別を行う場合など、ドメインは、セッションが異なるネットワークと異なるエンドポイントから到達できることを認識すべきです。その結果、サービス識別アルゴリズムが完了していなければならない - それが受信されるかもしれない可能性のあるシグナリングメッセージと設定される可能性があります任意のセッションのために最良の答えを計算意味します。
In a homogeneous environment, the process of service identification is easy. The service provider will know the set of services they are providing, and based on the specific call flows for each specific service, can construct rules to differentiate one service from another. However, when different providers interconnect, or when different endpoints are introduced, assumptions about what services are used, and how they are signaled, no longer apply. To provide the best user experience possible, a provider doing service identification needs to perform a "best-match" operation, such that any legal SIP signaling -- not just the specific call flows running within their own network amongst a limited set of endpoints -- is mapped to the appropriate service.
均質な環境では、サービス識別のプロセスは簡単です。サービスプロバイダは、別の1つのサービスを区別するためにルールを構築することができ、それぞれ特定のサービスのための具体的なコールフローに基づいて、彼らが提供しているサービスのセットを知っている、となります。しかし、異なるプロバイダの相互接続、またはときに別のエンドポイントは、サービスが使用されているかについての仮定を導入されていない、そしてそれらがどのように通知され、もはや適用されます。可能な限り最高のユーザーエクスペリエンスを提供するために、サービス識別を行っているプロバイダが、「ベストマッチ」操作を実行する必要があり、そのような法的なSIPシグナリングこと - だけでなく、特定の呼び出しは、エンドポイントの限られたセットの中で、自分のネットワーク内で実行されている流れ - - 適切なサービスにマッピングされます。
Presence can help a great deal with providing unique URIs for different services. When a user wishes to contact another user, and knows only the AOR for the target (which is usually the case), the user can fetch the presence document for the target. That document, in turn, can contain numerous service URIs for contacting the target with different services. Those URIs can then be used in the Request-URI for differentiation. When possible, this is the best solution to the problem.
プレゼンスは異なるサービスに一意のURIを提供するとともに大いに役立ちます。ユーザが別のユーザに連絡することを望む、と（通常の場合）標的に対してのみAORを知っている場合、ユーザは、ターゲットのプレゼンスドキュメントをフェッチすることができます。その文書には、順番に、さまざまなサービスをターゲットに接触させるための多数のサービスのURIを含めることができます。それらのURIは、差別化のためのRequest-URIに使用することができます。可能な場合、これは問題に最適なソリューションです。
Service identifiers themselves are not bad; derived service identification allows each domain to cache the results of the service identification process for usage by another network element within the same domain. However, service identifiers are fundamentally useful within a particular domain, and any such header must be stripped at a network boundary. Consequently, the process of service identification and their associated service identifiers is always an intra-domain operation.
サービス識別子自体は悪くありません。誘導されたサービスの識別は、各ドメインが同じドメイン内の別のネットワーク要素によって使用するためのサービス識別処理の結果をキャッシュすることを可能にします。しかし、サービス識別子は、特定のドメイン内に基本的に有用であり、任意のそのようなヘッダは、ネットワーク境界で剥離されなければなりません。結果として、サービス識別およびそれに関連するサービス識別子のプロセスは、常にドメイン内の動作です。
Device dispatch should be done following the principles of [RFC3841], using implicit preferences based on the signaling. For example, [RFC5688] defines a new UA capability that can be used to dispatch requests based on different types of application media streams.
デバイスのディスパッチは、シグナリングに基づく暗黙的なプリファレンスを使用して、[RFC3841]の原理次行われるべきです。例えば、[RFC5688]は、アプリケーションのメディアストリームの異なるタイプに基づいて要求をディスパッチするのに使用することができる新たなUAの能力を定義します。
However, it is a mistake to try and use a service identifier as a UA capability. Consider a service called "multimedia telephony", which adds video to the existing PSTN experience. A user has two devices, one of which is used for multimedia telephony and the other strictly for a voice-assisted game. It is tempting to have the telephony device include a UA capability [RFC3840] called "multimedia telephony" in its registration. A calling multimedia telephony device can then include the Accept-Contact header field [RFC3841] containing this feature tag. The proxy serving the called party, applying the basic algorithms of [RFC3841], will correctly route the call to the terminating device.
しかし、試してみて、UAの機能として、サービス識別子を使用するのは間違いです。既存のPSTNの経験にビデオを追加する「マルチメディア電話」と呼ばれるサービスを、考えてみましょう。ユーザーは、マルチメディア電話と音声支援のゲームのための厳密に他のために使用されているそのうちの一つ二つのデバイスを持っています。その登録に「マルチメディア電話」と呼ばれるUA機能[RFC3840]を含んテレフォニーデバイスを持っている魅力的です。呼び出しマルチメディア電話装置は、この機能タグを含むのAccept-Contactヘッダーフィールド[RFC3841]を含むことができます。プロキシは、終端装置へのルートの呼び出しを正しく、[RFC3841]の基本的なアルゴリズムを適用するだろう、と呼ばれるパーティにサービスを提供します。
However, if the calling party is not within the same domain, and the calling domain does not know about or use this feature tag, there will be no Accept-Contact header field, even if the calling party was using a service that is a good match for "multimedia telephony". In such a case, the call may be delivered to both devices, but it will yield a poorer user experience. That's because device dispatch was done using declarative service identification.
発呼者が同じドメイン内ではなく、呼び出し元のドメインが知っているか、この機能のタグを使用していない場合、発呼者は良いがサービスを使用していた場合でも、しかし、、、何のAccept-Contactヘッダーフィールドは存在しません「マルチメディア電話」の一致。そのような場合には、コールは両方のデバイスに配信することができるが、それは貧しいユーザーエクスペリエンスが得られます。デバイスの発送は、宣言サービス識別を使用して行われていたからです。
The best way to avoid this problem is to use feature tags that can be matched to well-defined signaling features -- media types, required SIP extensions, and so on. In particular, the golden rule is that the granularity of feature tags must be equivalent to the granularity of individual features that can be signaled in SIP.
ようにメディアタイプ、必要なSIPの拡張、および - この問題を回避する最善の方法は、明確に定義されたシグナリング機能に一致させることができる機能タグを使用することです。具体的には、黄金のルールが機能タグの粒度はSIPでシグナリングすることができる個々の機能の粒度と同等でなければならないということです。
Oftentimes, the service associated with a request is utilized for purposes such as authorization, accounting, and billing. When service identification is not done properly, the possibility of unauthorized service use and network fraud is introduced. It is for this reason, discussed extensively in Section 6.1, that the usage of declarative service identifiers inserted by a UA is not recommended.
多くの場合、要求に関連付けられたサービスは、許可、アカウンティング、および課金などの目的のために利用されています。サービス識別が適切に行われていない場合は、不正なサービス利用とネットワーク詐欺の可能性が導入されます。これは、UAによって挿入された宣言型サービス識別子の使用が推奨されていないことを、6.1節で広く議論し、この理由です。
This document is based on discussions with Paul Kyzivat and Andrew Allen, who contributed significantly to the ideas here. Much of the content in this document is a result of discussions amongst participants in the SIPPING mailing list, including Dean Willis, Tom Taylor, Eric Burger, Dale Worley, Christer Holmberg, and John Elwell, amongst many others. Thanks to Spencer Dawkins, Tolga Asveren, Mahesh Anjanappa, and Claudio Allochio for reviews of this document.
この文書は、ここでのアイデアに大きく貢献ポールKyzivatとアンドリュー・アレン、との協議に基づいています。このドキュメントのコンテンツの多くは、他の多くの中・ディーンウィリス、トム・テイラー、エリック・バーガー、デイル・ウォーリー、クリステルHolmbergの、ジョンエルウェル含むSIPPINGメーリングリストの参加者の中での議論、の結果です。このドキュメントのレビューのためのスペンサードーキンストルガAsveren、マヘシュAnjanappa、そしてクラウディオAllochioに感謝します。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479]ローゼンバーグ、J.、 "プレゼンスのためのAデータモデル"、RFC 4479、2006年7月。
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", RFC 4485, May 2006.
[RFC4485]ローゼンバーグ、J.とH. Schulzrinneと、RFC 4485、2006年5月 "セッション開始プロトコル（SIP）への拡張の作者のためのガイドライン"。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]キャンベル、B.、マーイ、R.、およびC.ジェニングス、 "メッセージセッションリレープロトコル（MSRP）"、RFC 4975、2007年9月。
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[RFC5031] Schulzrinneと、H.、 "ユニフォームリソース名救急およびその他のよく知られているサービスのための（URN）"、RFC 5031、2008年1月。
[ECRIT-FRAMEWORK] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling using Internet Multimedia", Work in Progress, July 2009.
[ECRIT-FRAMEWORK]ローゼン、B.、Schulzrinneと、H.、ポーク、J.、およびA.ニュートン、 "インターネットマルチメディアを使用して、緊急コールのためのフレームワーク" が進歩、2009年7月ワーク。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627]ローゼンバーグ、J.、RFC 5627、2009年10月 "セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザエージェントのURI（GRUUs）の取得と使用" を参照してください。
[RFC5688] Rosenberg, J., "A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes", RFC 5688, January 2010.
[RFC5688]ローゼンバーグ、J.、 "Aセッション開始プロトコル（SIP）MIMEアプリケーションのサブタイプのためのメディア特徴タグ"、RFC 5688、2010年1月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、 "セッション開始プロトコル（SIP）のための発信者が設定"、RFC 3841、2004年8月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
Author's Address
著者のアドレス
Jonathan Rosenberg jdrosen.net Monmouth, NJ USA
ジョナサン・ローゼンバーグjdrosen.netモンマス、NJ USA
EMail: jdrosen@jdrosen.net URI: http://www.jdrosen.net
電子メール：jdrosen@jdrosen.net URI：http://www.jdrosen.net