[要約] RFC 5897は、SIPでの通信サービスの識別に関する標準化を目的としています。このRFCは、SIPメッセージ内の通信サービスの識別情報の構造と使用方法を定義しています。
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)
セッション開始プロトコル（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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
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ライセンステキストを含める必要があります。
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は、エージェント間で幅広いセッションタイプを可能にします。低ビトレートの音声のみからマルチチャネルの高忠実度の音楽まで、オーディオセッションを管理できます。小さな「Talking-Head」スタイルのビデオチャットから、高解像度のマルチポイントビデオ会議まで、低帯域幅のユーザー生成コンテンツ、高解像度の映画やテレビコンテンツまでの範囲のビデオセッションを管理できます。SIPエンドポイントは何でもできます - 古いアナログ電話をVoice over 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の最大の資産ですが、多くの課題も導入しています。これらの1つは、エンドポイントがセッションのSIP招待状を生成する場合、またはセッションを受信すると、そのセッションが任意の数の異なるユースケースとエンドポイントタイプのコンテキスト内にある可能性があることです。たとえば、単一のオーディオストリームを備えたSIP招待状は、モバイルデバイス間のプッシュツートークセッション、ソフトフォン間の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で可能な異なるサービスは、実装者とシステム設計者がサービス識別のためのテクニックを求めるように駆り立てました。サービス識別とは、ユーザーエージェントによって生成されるシグナル伝達を促進している特定のユースケースを決定および/または信号するプロセスです。一見すると、これは無害で簡単に思えます。たとえば、新しいヘッダー「Service-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. サービスのIDは、プロトコルメッセージやその他のコンテキスト情報の明示的なシグナリングから常に導き出され、メッセージに配置された別の識別子を介してユーザーが示すことはありません。
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.
2. シグナリングメッセージに基づくサービス識別のプロセスは、SIPの交渉的な表現力をSIPするように設計する必要があり、したがって、不均一性を処理し、固定されたユースケースを想定しないでください。
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. 存在は、特定のサービスに接続するために利用できるURIを提供するのに役立ち、それにより、サービスIDの導出に使用できるシグナル伝達に明示的な適応症を作成します。
4. Service identities placed into signaling messages for the purposes of caching the service identity are strictly for intra-domain usage.
4. サービスアイデンティティがサービスアイデンティティをキャッシュする目的でシグナリングメッセージに配置されたサービスアイデンティティは、ドメイン内の使用に関する厳密に行われます。
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]の存在データモデルは、サービスの概念を、存在が説明するコア概念の1つとして定義しています。サービスは、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）の任意のエンドポイントとの音声通信、またはユーザーによって呼び出されるさまざまなアプリケーションとチャット（Aからプッシュツートークアプリケーションを手動で選択するワイヤレス電話とテレフォニーアプリケーション）。通話以外では、ユーザーエクスペリエンスの違いは、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. 特定の信号交換を推進している基礎となるサービスを決定する、
2. associating that service with a service identifier, and
2. そのサービスをサービス識別子に関連付けます
3. attaching that moniker to a signaling message (typically a SIP INVITE).
3. そのモニカーを信号メッセージに添付します（通常、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.
モバイルデバイスから2人のユーザーの間で再生されるインタラクティブなゲームを検討してください。このゲームでは、ユーザーが音声に加えて、メッセージングチャネルを使用して、お互いのゲームの動きを送信します。別のサービスでは、ユーザーは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）に招待を送信します。ただし、これらはユーザーエクスペリエンスの観点から、かなり異なるサービスを表しています。
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.
これを2人のユーザー間の基本的な電話と比較してください。どちらも単一のオーディオセッションを伴います。どちらも同じコーデックを使用します。それらは同一であるように見えます。ただし、さまざまなユーザーエクスペリエンスが必要です。たとえば、従来のテレフォニー機能（コール転送やコールスクリーニングなど）が電話サービスに適用されますが、ゲームチャットサービスには適用されません。
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メッセージメソッド[RFC3428]は、特定のAORにワンショットメッセージを送信する方法を提供します。この仕様は、主に、ワイヤレス電話で一般的に見られるショートメッセージサービス（SMS）スタイルメッセージングを対象としています。メッセージリクエストの受領により、電話でメッセージングアプリケーションが起動し、ユーザーがメッセージ履歴を閲覧して応答できるようになります。
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.
ただし、メッセージ要求は、他の目的でデバイスにコンテンツを配信するために使用される場合があります。たとえば、一部のプロバイダーはそれを使用して、新しい電話設定やパラメーターなどの構成更新を提供したり、新しいバージョンのファームウェアが利用可能であることを示します。この目的のために設計されていませんが、既存のワイヤレスネットワークではSMSがこの目的に使用され、メッセージ要求はSIPに相当するSMSに相当するため、メッセージメソッドが使用されます。
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.
したがって、電話に送信されたメッセージ要求は、2つの異なるサービスの場合があります。1つはメッセージングアプリの呼び出しが必要ですが、もう1つは電話のソフトウェアによって消費され、ユーザーのやり取りはまったくありません。
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.
既知であれば、サービスアイデンティティが利用されるものを理解することが重要です。このセクションでは、主要な用途について説明します。これらは、ユーザーエージェントとネットワークでのアプリケーションの呼び出し、サービスの承認の質、サービス承認、会計と請求、サービス交渉、およびデバイスの派遣です。
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ユーザーエージェントの実装を利用することです。着信招待状またはメッセージが届くときは、適切なアプリケーションソフトウェアに配信する必要があります。各サービスが異なるソフトウェアアプリケーションにバインドされている場合、メッセージを適切なソフトウェアに送信するためにサービスIDが必要であるように思われます。これを図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のサービスの例では、ゲームサービスへの着信招待状がゲームアプリケーションソフトウェアに配信されます。音声チャットサービスへの着信の招待状は、音声チャットアプリケーションソフトウェアに配信されます。セクション3.3の例は似ています。セクション3.4の例では、ユーザー間メッセージのメッセージ要求がメッセージングまたはSMSアプリに配信され、構成データを含むメッセージリクエストが構成更新アプリケーションに配信されます。
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.
ただし、Webとは異なり、3つのユースケースすべてで、ユーザーが通信を開始する（または以下にあるように見えます）（以下のように見えます）、受信者の識別子は1つの識別子であるAORです。その結果、SIPリクエスト-RIは、3つすべてのケースで同一であるため、ディスパッチに使用することはできません。
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のユーザーエージェントによって発行された招待状は、ユーザーがそのコンテンツにアクセスできるかどうかを許可して、ある種のコンテンツ権管理を行うサーバーを通過します。一方、マルチメディア会議のためにユーザーが発行した招待状は、アウトバウンドコールスクリーニングやコールレコーディングなどの「従来の」テレフォニー機能を提供するサーバーを通過します。IPTVに関連する招待状がアウトバウンドコールスクリーニングとコール録音が適用されることは意味がありません。また、マルチメディア会議招待がコンテンツライツマネジメントサーバーによって処理されることは意味がありません。実際、これらの場合、それは単なる効率の問題（必要でないときにサーバーを呼び出す）ではなく、本当に間違った動作が発生する可能性があります。たとえば、友人や家族の電話番号を除くすべてのものへのアウトバウンドコールをブロックするようにアウトバウンドコールスクリーニングアプリケーションが設定されている場合、そのようなサーバーによって処理されるIPTV要求はブロックされます（AのAORをターゲットにしていないため友人や家族）。これにより、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で説明されているメッセージ要求は、チャットに関連付けられている場合はフィルタリングのためにメッセージサーバーを通過する必要がありますが、構成の更新に関連付けられている場合はそうではありません。
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.
メッセージ要求に適用されるフィルターを考えてみてください。そのフィルターは、ネットワーク内のサーバーで実行されます。フィルター操作により、ユーザージョーは、ジョーとボブが株式取引について議論することを禁止するいくつかの規制のために、「株」または「購入」という言葉を含むユーザーボブにメッセージを送信することを防ぎます。ただし、構成目的のメッセージには、トークン「ストック」を何らかの属性として使用する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ネットワークは、さまざまなレベルのサービス品質（QOS）をIPパケットに提供できます。このサービスには、保証されたスループット、レイテンシ、または損失特性が含まれます。通常、ユーザーエージェントは、明示的なシグナル伝達プロトコル（リソース予約プロトコル（RSVP）[RFC2205]など）を使用するか、パケットのdiffserv値のマーキングを使用して、何らかのQoS要求を行います。ネットワークは、これらのQoS治療が許可されているかどうかに基づいてポリシー決定を行う必要があります。一般的な承認ポリシーの1つは、ユーザーが呼び出しを許可されている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の場合ではなく、それを承認できることを選択します。これには、セッションを設定した招待に関連するサービスを知るために、QoS許可を実行するサーバーが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.
したがって、ネットワーク内のサーバーに招待状が到着すると、サーバーが承認決定を下すことができるように、サーバーは要求されたサービスが何であるかを判断する必要があります。
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つは、サービスの種類に基づいて異なる方法で請求されていることです。その結果、サービスアイデンティティの目標の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の場合、サービスプロバイダーはコンテンツに基づいて請求できます（おそらく映画ごとに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つのデバイスがある場合（ゲームサービスをサポートできる1つとできないデバイス）、ゲームセッションをサポートするデバイスに招待状を発送する必要があります。。
In this section, we describe several key principles of service identification:
このセクションでは、サービス識別のいくつかの重要な原則について説明します。
1. Services are a by-product of signaling
1. サービスはシグナリングの副産物です
2. Identical signaling produces identical services
2. 同一のシグナリングは同一のサービスを生成します
3. Declarative service identification is an example of "Do What I Mean" (DWIM)
3. 宣言的なサービス識別は、「私が意味することをする」（DWIM）の例です
4. Declarative service identifiers are redundant
4. 宣言サービス識別子は冗長です
5. URIs are a key mechanism for producing differentiated signaling
5. URIは、分化したシグナル伝達を生成するための重要なメカニズムです
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.
サービスとは、シグナリングとその周辺のコンテキストの副産物（ユーザープロファイル、時刻など）です。これは、ネットワークに起動したシグナリングメッセージの効果です。したがって、サービスアイデンティティは、追加の識別子なしで、常にシグナリングとそのコンテキストから導出可能です。言い換えれば、シグナリングが適切に処理されている場合、導出されたサービス識別が常に可能です。
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サーバーでその要求をターゲットにし、オーディオおよびビデオストリーミング用のセッション説明プロトコル（SDP）を含めると、そのような招待を送信する *結果 *はIPTVセッションが発生することです。招待の全体的な目的は、そのようなセッションを確立することであり、したがって、サービスを呼び出すことです。したがって、サービスは、シグナリングメッセージの他の部分とは異なるものではありません。サービスは、ネットワークと他のユーザーエージェントがシグナリングメッセージを処理した後にユーザーが取得するものです。
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を欠いているリクエストを招待する）により、派生サービス識別を実行することが不可能になるように思われるかもしれません。結局のところ、上記のいくつかのケースでは、リクエストでSDPを使用して差別化が行われました。そこにない場合はどうなりますか？答えは簡単です - それがそこになく、SDPが呼び出されたパーティーによって提供されている場合、実際に招待時にサービスを知ることはできません。それが遅れたオファーの全体的なポイントです - 呼び出されたパーティーにセッションに望むものを提供する機会を与えます。リクエスト時にサービス識別が必要な場合、遅延オファーを使用できません。
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の例からは、異なるサービスがあるが、同一のシグナル伝達があるように思われます。私たちがアサーションに忠実である場合、実際には1つの論理的な結論があります。
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つ以上が真実であるためです。
1. there is in fact something different that has been overlooked
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の場合、リクエストはメディアサーバーまたは表示される特定のコンテンツを対象としています。マルチメディア会議の場合、ターゲットは会議サーバーです。したがって、ドメインの管理者は、リクエスト-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を使用して、ゲームに関連付けられている電話機の音声チャット機能を識別するために使用できます（たとえば、グローバルにルーティング可能なユーザーエージェントURI（GRUU）を使用できます。[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.
構成vs.ページャーメッセージング：ゲームと音声チャットの場合と同様に、メッセージのコンテンツタイプは、メッセージの結果として発生するサービスを区別します。
"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番目のゲームの例では、最終的には2つのサービス間で異なる（またはそうすべき）リクエスト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.
リクエスト-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の例に再び戻って、ユーザー自身ではなく、ユーザーの電話のソフトウェアインスタンスでゲームチャットセッションをターゲットにする方が理にかなっていることがわかります。ゲームチャットセッションは、ユーザーがゲームをプレイしている電話のみに行く必要があります。ソフトウェアインスタンスは実際にその携帯電話でのみ生きていますが、ユーザー自体に多くの方法で連絡することができます。ゲームチャットセッションに呼び出されたテレフォニー機能は必要ありません。なぜなら、これらの機能は、誰かがユーザーと通信しようとしているときにのみ意味があるからです。誰かがユーザーに代わって行動するソフトウェアインスタンスと通信しようとしている場合、リクエストのターゲットが完全に異なるため、異なるルールのセットが適用されます。
Based on these principles, several perils of declarative service identification can be described. They are:
これらの原則に基づいて、宣言的サービス識別のいくつかの危険を説明できます。彼らです：
1. Declarative service identification can be used for fraud
1. 宣言的なサービス識別は、詐欺に使用できます
2. Declarative service identification can hurt interoperability
2. 宣言的なサービス識別は、相互運用性を損なう可能性があります
3. Declarative service identification can stifle service innovation
3. 宣言的なサービス識別は、サービスの革新を抑制することができます
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セッションへの招待を送信できますが、マルチメディア会議を示すサービス識別子を含めることができます。ユーザーは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フレームワーク]。ユーザーが電話をかけられない場合でも無料で許可されているなど、緊急サービスの呼び出しを特別な扱いに提供することが望ましいです。緊急通話が緊急サービスのurn [RFC5031]であるというターゲット以外の何かを通じて緊急コールが示された場合、詐欺の道を開くでしょう。ユーザーは、任意の任意のURIをリクエストURIに配置し、宣言的識別子を介して個別に示すことができます。コールが緊急サービスの呼び出しであることを示します。これは特別な治療を受けますが、もちろんターゲットURIにルーティングされます。この詐欺を防ぐ唯一の方法は、標的が緊急サービスのurnである任意の呼び出しと緊急電話を考慮することです。したがって、ここでのサービス識別は、リクエストのターゲットに基づいています。ターゲットが緊急サービスのURNである場合、リクエストは特別な治療を受けることができます。ユーザーは嘘をつくことはできません。なぜなら、これが緊急の骨nをターゲットにすることに加えて、これが緊急電話であることを個別に示す方法はないからです。
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認証などの機能を駆動する場合、このフィールドが適切に設定されていない場合に間違ったことが発生する可能性があることを意味します。ドメイン1のユーザーを検討し、ドメイン2のユーザーを呼び出します。ドメイン1は、ユーザーに「音声チャット」と呼ばれるサービスを提供します。これは、音声とIMをリアルタイムの会話に使用し、バディリストアプリケーションから追い出されます。PC。Domain 2は、ユーザーが「テキストテレフォニー」と呼ぶサービスをユーザーに提供します。これは、ユーザーがテキストメッセージを送信できるワイヤレスデバイスの音声サービスです。ドメイン1とドメイン2の両方がユーザーエージェントにサービス識別子をリクエストに挿入し、それを使用してQoS認証、会計、およびネットワークおよびデバイス内のアプリケーションの呼び出しを実行する場合を考えてください。ドメイン1のユーザーは、ドメイン2のユーザーを呼び出し、識別子「音声チャット」を招待に挿入します。これがドメイン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は、細かく粒状レベルで機能を交渉するための豊富なツールで構築されました。1人のユーザーエージェントは、オーディオとビデオを使用して電話をかけることができますが、受信UAがオーディオのみをサポートする場合、SIPは双方が最も低い一般的な分母に交渉することができます。したがって、コミュニケーションはまだ提供されています。別の例として、1人のエージェントがプッシュツートークセッション（コンパニオンフロアコントロールメカニズムを備えたオーディオ）を開始し、反対側は通常のオーディオのみを実行した場合、SIPは通常の音声通話に戻ることができます。別の例として、呼び出しユーザーエージェントが高解像度のビデオ会議エンドポイントを実行している場合、呼び出されたユーザーエージェントが通常のビデオエンドポイントのみをサポートしている場合、コーデック自体はより低いレート、画像サイズなどに下方に交渉できます。したがって、相互運用性が達成されます。興味深いことに、最終的な「サービス」は、元の招待状に配置されていたサービス識別子によって、もはや特徴付けられていない場合があります。たとえば、この場合、発信者からの元の招待にサービス識別子「Hi-Fiビデオ」が含まれていたが、ビデオがより低いレートと画像サイズに交渉された場合、サービス識別子は本当に適切ではありません。シグナリング自体が異なるドメイン間の交渉と相互運用性を提供するため、サービスはシグナリングによって導き出される必要がある理由です。
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.
実際、Metcalfeの法律では、ネットワークの価値は参加者の数の平方とともに増加していると述べています。この結果、大量の大きなドメインが集まり、一連のサービスに同意し、それらのサービスの有名な識別子のセットに同意すると、他のプロバイダーにも同じサービスを展開するように強制されます。相互接続がもたらす値を取得するため。これにより、革新が抑制され、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.
次の例を考えてください。いくつかのプロバイダーが集まり、多数のサービス識別子を標準化します。これらの1つは、オーディオとビデオを使用しています（「マルチメディアの会話」など）。このサービスは成功しており、広く利用されています。エンドポイントは、適切なソフトウェアアプリケーションにコールをディスパッチするこの識別子を探します。ネットワークは、機能を呼び出し、会計を実行し、QoSを提供するためにそれを探します。新しいプロバイダーは、新しいサービスのアイデアを取得します（「アバター強化マルチメディアの会話」など）。このサービスでは、オーディオとビデオがありますが、アバターをレンダリングする3番目のストリームがあります。発信者は、電話でボタンを押して、他の人のデバイスのアバターに感情を示したり、騒音を出したりすることができます。これは、IMで今日の絵文字が使用される方法に似ています。このサービスは、SDPに3番目のメディアストリーム（および3番目の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.
通常、このサービスは、通常のオーディオビデオエンドポイントを使用して後方互換性があり、3番目のメディアストリームを拒否するだけです。ただし、トークン「マルチメディアの会話」とそれに関連するオーディオビデオサービスを見ることを期待している大規模なネットワークが展開されているため、新しいプロバイダーがこの新しいサービスを展開することはほとんど不可能です。もしそうなら、ユーザーが他のプロバイダードメインのユーザーを呼び出すと、完全に失敗するか、部分的に失敗します。
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.
現在標準で定義されているシグナリングがサービスを識別するのに十分ではないと思われる場合、それは必要なものを伝えるのに十分なシグナル伝達がないためである可能性があります。。セクション5.3で説明されているLitmusテストを適用することにより、ネットワーク設計者は、システムが宣言的サービス識別を実行しようとしているかどうかを判断できます。
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の重要な強みの1つは、参加者間のセッションの共通の見解を交渉する能力です。これは、最終的に受け取ったサービスが、コールのエンドポイントのタイプとその機能によって大きく異なる可能性があることを意味します。実際、この事実は、ドメイン間で呼び出しが設定されるとさらに明白になります。
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.
均一な環境では、サービス識別のプロセスは簡単です。サービスプロバイダーは、提供するサービスのセットを知り、特定のサービスごとに特定のコールフローに基づいて、あるサービスを別のサービスと区別するためのルールを構築できます。ただし、異なるプロバイダーが相互に接続した場合、または異なるエンドポイントが導入された場合、どのサービスが使用されているか、どのようにシグナルにされるかについての仮定はもはや適用されません。可能な限り最高のユーザーエクスペリエンスを提供するために、サービス識別を行うプロバイダーは、「ベストマッチ」操作を実行する必要があります。 - 適切なサービスにマッピングされます。
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は、リクエスト-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エクスペリエンスにビデオを追加する「マルチメディアテレフォニー」と呼ばれるサービスを検討してください。ユーザーには2つのデバイスがあり、そのうちの1つはマルチメディアテレフォニーに使用され、もう1つは音声支援ゲームに厳密に使用されます。テレフォニーデバイスには、登録に「マルチメディアテレフォニー」と呼ばれるUA機能[RFC3840]が含まれていることは魅力的です。通話マルチメディアテレフォニーデバイスには、この機能タグを含むAccept-Tontactヘッダーフィールド[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.
ただし、呼び出しパーティーが同じドメイン内になく、呼び出しドメインがこの機能タグについて知らない、または使用していない場合、呼び出しの当事者が良いサービスを使用していても、受け入れコンタクトヘッダーフィールドはありません。「マルチメディアテレフォニー」と一致します。そのような場合、通話は両方のデバイスに配信される場合がありますが、ユーザーエクスペリエンスが低下します。これは、宣言的なサービス識別を使用してデバイスディスパッチが行われたためです。
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.
多くの場合、リクエストに関連するサービスは、承認、会計、請求などの目的で利用されます。サービス識別が適切に行われない場合、不正なサービスの使用とネットワーク詐欺の可能性が導入されます。このため、セクション6.1で広く議論されているため、UAによって挿入された宣言的サービス識別子の使用法が推奨されません。
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.
このドキュメントは、ここのアイデアに大きく貢献したポール・キジバットとアンドリュー・アレンとの議論に基づいています。このドキュメントのコンテンツの多くは、ディーン・ウィリス、トム・テイラー、エリック・バーガー、デール・ウォーリー、クリスター・ホルムバーグ、ジョン・エルウェルなど、すすり泣くメーリングリストの参加者間の議論の結果です。この文書のレビューについては、スペンサー・ドーキンス、トルガ・アスベレン、マヘシュ・アンジャナッパ、クラウディオ・アロチオに感謝します。
[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月。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479] Rosenberg、J。、「存在のためのデータモデル」、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] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）への拡張著者のためのガイドライン」、RFC 4485、2006年5月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975] Campbell、B.、Mahy、R。、およびC. Jennings、「The Message Session Relay Protocol（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] Rosen、B.、Schulzrinne、H.、Polk、J。、およびA. Newton、「インターネットマルチメディアを使用した緊急通話のフレームワーク」、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] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェントURIS（Gruus）の取得と使用」、RFC 5627、2009年10月。
[RFC5688] Rosenberg, J., "A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes", RFC 5688, January 2010.
[RFC5688] Rosenberg、J。、「MIMEアプリケーションサブタイプのセッション開始プロトコル（SIP）メディア機能タグ」、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] Campbell、B.、Rosenberg、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] Rosenberg、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] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[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] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
Author's Address
著者の連絡先
Jonathan Rosenberg jdrosen.net Monmouth, NJ USA
Jonathan Rosenberg Jdrosen.net Monmouth、NJ USA
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net