[要約] RFC 5638は、エンドポイントでのアプリケーションのためのシンプルなSIP使用シナリオを提供しています。このRFCの目的は、エンドポイントでのSIPの使用方法を明確にし、アプリケーションの開発と統合を容易にすることです。
Network Working Group H. Sinnreich, Ed.
Request for Comments: 5638 Adobe
Category: Informational A. Johnston
E. Shim
Avaya
K. Singh
Columbia University Alumni
September 2009
Simple SIP Usage Scenario for Applications in the Endpoints
エンドポイントのアプリケーションのシンプルなSIP使用シナリオ
Abstract
概要
For Internet-centric usage, the number of SIP-required standards for presence and IM and audio/video communications can be drastically smaller than what has been published by using only the rendezvous and session-initiation capabilities of SIP. The simplification is achieved by avoiding the emulation of telephony and its model of the intelligent network. 'Simple SIP' relies on powerful computing endpoints. Simple SIP desktop applications can be combined with rich Internet applications (RIAs). Significant telephony features may also be implemented in the endpoints.
インターネット中心の使用については、SIPのランデブーとセッション開始機能のみを使用して公開されているものよりも、存在感とIMおよびオーディオ/ビデオ通信に関するSIPが必要な基準の数を劇的に小さくすることができます。単純化は、テレフォニーのエミュレーションとインテリジェントネットワークのモデルを回避することで達成されます。「Simple SIP」は、強力なコンピューティングエンドポイントに依存しています。シンプルなSIPデスクトップアプリケーションは、リッチインターネットアプリケーション（RIA）と組み合わせることができます。エンドポイントに重要なテレフォニー機能も実装できます。
This approach for SIP reduces the number of SIP standards with which to comply -- from roughly 100 currently, and still growing, to about 11.
SIPのこのアプローチは、現在の約100からまだ成長しているSIP標準の数を減らします。
References for NAT traversal and for security are also provided.
NATトラバーサルおよびセキュリティに関する参照も提供されます。
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 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 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. The Endpoint in the SIP and Web Architectures ...................5
2.1. The Telephony Gateway as a SIP Endpoint ....................6
3. Applicability for Simple SIP in the Endpoints ...................7
3.1. What Simple SIP Can Accomplish .............................7
3.2. Baseline for Simple SIP ....................................7
3.3. What Simple SIP May or May Not Accomplish ..................8
3.4. What Is Out of Scope for Simple SIP ........................8
3.5. Borderline Cases ...........................................9
4. Mandatory SIP References for Internet-Centric Usage .............9
4.1. RFC 3261: "SIP: Session Initiation Protocol" ..............10
4.2. RFC 4566: "SDP: Session Description Protocol" .............10
4.3. RFC 3264: "An Offer/Answer Model with Session
Description Protocol (SDP)" ...............................10
4.4. RFC 3840: "Indicating User Agent Capabilities in
the Session Initiation Protocol (SIP)" ....................10
4.5. RFC 3263: "Session Initiation Protocol (SIP):
Locating SIP Servers" .....................................11
4.6. RFC 3265: "Session Initiation Protocol
(SIP)-Specific Event Notification" ........................11
4.7. RFC 3856: "A Presence Event Package for the
Session Initiation Protocol (SIP)" ........................11
4.8. RFC 3863: "Presence Information Data Format (PIDF)" .......11
4.9. RFC 3428: "Session Initiation Protocol (SIP)
Extension for Instant Messaging" ..........................12
4.10. RFC 4474: "Enhancements for Authenticated
Identity Management in the Session Initiation
Protocol (SIP)" ..........................................12
4.11. RFC 3581: "An Extension to the Session Initiation
Protocol (SIP) for Symmetric Response Routing" ...........12
4.12. Updates to SIP-Related Protocols .........................12
5. SIP Applications in the Endpoints ..............................12
6. NAT Traversal ..................................................14
7. Security Considerations ........................................14
8. Acknowledgements ...............................................15
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
The Session Initiation Protocol (SIP) has become the global standard for real-time multimedia communications over the Internet and in private IP networks, due to its adoption by service providers and in enterprise networks alike. The cost of this success has been a continuing increase in complexity to accommodate the various requirements for such networks. At the same time, the World Wide Web has become the platform for a boundless variety of rich Internet applications (RIAs), both in the browser and on the desktop. For SIP to be useful for RIAs, requirements for legacy voice-service providers that add unnecessary complexity may be avoided by delegating the interworking to telephony gateway endpoints. This usage scenario for SIP requires following the end-to-end principle of the Internet architecture at the application level or, in other words, placing SIP applications in the endpoints.
セッション開始プロトコル（SIP）は、サービスプロバイダーやエンタープライズネットワークによる採用により、インターネットおよびプライベートIPネットワークを介したリアルタイムマルチメディア通信のグローバル標準となっています。この成功のコストは、そのようなネットワークのさまざまな要件に対応するための複雑さの継続的な増加でした。同時に、World Wide Webは、ブラウザとデスクトップの両方で、無限の種類のリッチインターネットアプリケーション（RIA）のプラットフォームになりました。SIPがRIASに役立つためには、不必要な複雑さを追加するレガシー音声サービスプロバイダーの要件は、インターワーキングをテレフォニーゲートウェイエンドポイントに委任することで回避できます。SIPのこの使用シナリオでは、アプリケーションレベルでのインターネットアーキテクチャのエンドツーエンドの原則に従うか、つまりSIPアプリケーションをエンドポイントに配置する必要があります。
There are several reasons, from the Web service's perspective, to place most or all SIP applications in the endpoints and just use the client-server (CS) or peer-to-peer (P2P) rendezvous function for SIP:
Webサービスの観点から、エンドポイントにほとんどまたはすべてのSIPアプリケーションを配置し、SIP用のクライアントサーバー（CS）またはピアツーピア（P2P）ランデブー機能を使用する理由はいくつかあります。
1. Value proposition: SIP applications in the endpoints can be easily mixed with RIAs and thus enable service providers to offer new services in a scalable and flexible manner. Mixing SIP applications with RIAs also significantly enhances the value of SIP applications. Rich Internet applications support unrestricted user choice as an alternative that is beyond what is traditionally prepackaged as network-based communication service plans.
1. 価値提案：エンドポイントのSIPアプリケーションは、RIAと簡単に混合でき、サービスプロバイダーがスケーラブルで柔軟な方法で新しいサービスを提供できるようになります。SIPアプリケーションとRIASの混合も、SIPアプリケーションの価値を大幅に向上させます。リッチインターネットアプリケーションは、ネットワークベースのコミュニケーションサービスプランとして伝統的に事前にパッケージ化されているものを超える代替手段として、無制限のユーザーの選択をサポートしています。
2. Eliminating the problems associated with distributed SIP applications in various feature servers across the network allows us to greatly simplify SIP. There is also the Internet end-to-end principle, which argues that network intermediaries cannot completely understand the applications and their state in the endpoints.
2. ネットワーク上のさまざまな機能サーバーの分散SIPアプリケーションに関連する問題を排除すると、SIPを大幅に簡素化できます。また、インターネットのエンドツーエンドの原則もあります。これは、ネットワーク仲介業者がエンドポイントでアプリケーションとその状態を完全に理解できないと主張しています。
'Simple SIP' in this document refers the SIP functions necessary to support only the rendezvous and session-setup functions of SIP, voice, video, basic presence, instant messaging, and also security. Simple SIP is focused on providing a basic multimedia, real-time communications "call". This includes presence, instant messaging, voice, and video for point-to-point and various conference applications. One or a very small number of additional servers may also be provided; for example, a voice-mail server may be provided as an auxiliary to make a simple one-to-one call to voice mail if the callee does not answer or to check voice mail.
このドキュメントの「Simple SIP」は、SIP、音声、ビデオ、基本的な存在、インスタントメッセージング、セキュリティのランデブーおよびセッションセットアップ関数のみをサポートするために必要なSIP関数を指します。Simple SIPは、基本的なマルチメディア、リアルタイム通信「CALL」の提供に焦点を当てています。これには、ポイントツーポイントおよびさまざまな会議アプリケーションの存在感、インスタントメッセージング、音声、ビデオが含まれます。1つまたは非常に少数の追加サーバーも提供される場合があります。たとえば、Calleeが応答しない場合、またはボイスメールをチェックしない場合、ボイスメールに簡単な1対1の呼び出しを行うための補助としてボイスメールサーバーを提供することができます。
Once the applications in the endpoints have established basic communications, it is up to them to support available features selected by users. This paper is targeted to such scenarios. In telephony, most of the value to users and service providers alike is added by signaling. By contrast, on the Web, RIAs add most of the value. The integrated use of SIP and RIAs in the endpoints can combine the best of both.
エンドポイントのアプリケーションが基本的な通信を確立すると、ユーザーが選択した利用可能な機能をサポートするのは彼ら次第です。このペーパーは、そのようなシナリオを対象としています。電話では、ユーザーとサービスプロバイダーにとっての価値のほとんどがシグナリングによって追加されます。対照的に、ウェブ上では、RIASは値のほとんどを追加します。エンドポイントでのSIPとRIAの統合使用は、両方の最高のものを組み合わせることができます。
This approach limits the number of SIP standards to roughly 11 that are listed here as the core for simple SIP. At the time of this writing, the Real-Time Applications and Infrastructure (RAI) area of the IETF is focused on a dedicated working group for the core SIP protocol, separate from various SIP applications. We anticipate this emerging work will also be the core of what is termed here as simple SIP and will actually further reduce the number of references that reflect the present core SIP standards.
このアプローチにより、SIP標準の数は、単純なSIPのコアとしてここにリストされている約11に制限されます。この執筆時点では、IETFのリアルタイムアプリケーションとインフラストラクチャ（RAI）エリアは、さまざまなSIPアプリケーションとは別のコアSIPプロトコルの専用ワーキンググループに焦点を当てています。この新たな作業は、ここで単純なSIPと呼ばれるものの中核となると予想しており、実際に現在のコアSIP標準を反映する参照の数をさらに減らすことができます。
This memo aims to shield Web application developers from the need to know or understand more than the core SIP protocol. The total number of references has been kept to a minimum and includes other related topics, such as examples for providing telephony services in the endpoints, NAT traversal, and security. The referenced papers are, however, entry points to these knowledge resources. Readers interested in a more detailed list of SIP topics, especially telephony, can follow up the short list here with the extensive list in "A Hitchhikers' Guide to SIP", RFC 5411 [12]. The guide has over 140 references for understanding most, but not all, of the published features of SIP in the IETF and elsewhere. There is also a Web site that automatically tracks the number of SIP-related RFCs [13]. Other standards and commercial organizations have greatly enlarged the published features of SIP as well. We could not actually provide a complete count on everything that has been published as some form of SIP-standard document.
このメモは、Core SIPプロトコルよりも多くを知るか理解する必要性からWebアプリケーション開発者を保護することを目的としています。参照の総数は最小限に抑えられており、エンドポイントでテレフォニーサービスを提供するための例、NATトラバーサル、セキュリティなど、他の関連するトピックが含まれています。ただし、参照されている論文は、これらの知識リソースへのエントリポイントです。SIPトピック、特にテレフォニーのより詳細なリストに興味のある読者は、「SIPへのヒッチハイカーガイド」、RFC 5411 [12]の広範なリストで、ここで短いリストをフォローアップできます。このガイドには、IETFおよび他の場所でのSIPの公開された機能のすべてではなく、ほとんどを理解するための140以上の参照があります。SIP関連のRFCの数を自動的に追跡するWebサイトもあります[13]。他の基準や商業組織は、SIPの公開された機能も大幅に拡大しています。実際には、SIP標準のドキュメントの形として公開されているすべてのものに完全なカウントを提供することはできませんでした。
NAT traversal is also a basic requirement for simple SIP. However, given the potential option of using the Host Identity Protocol (HIP) in SIP-enabled endpoints, as shown in Section 4, simple SIP may not require any standards other than those mentioned here. The alternative to HIP is to use SIP-specific protocols for NAT traversal, such as STUN (Simple Traversal of the UDP Protocol through NAT), TURN (Traversal Using Relay NAT), and ICE (Interactive Connectivity Establishment), as discussed in Section 4.
NATトラバーサルは、単純なSIPの基本的な要件でもあります。ただし、セクション4に示すように、SIP対応エンドポイントでホストIDプロトコル（HIP）を使用する潜在的なオプションを考えると、単純なSIPはここで言及されているもの以外の標準を必要としない場合があります。股関節の代替品は、セクション4で説明したように、スタン（NATを介したUDPプロトコルの単純なトラバーサル）、ターン（reay NATを使用したトラバーサル）、ICE（インタラクティブ接続の確立）など、NATトラバーサルにSIP固有のプロトコルを使用することです。。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119で説明されていると解釈されます。
SIP has been defined in RFC 3261 for rendezvous and session initiation. The usual example is the trapezoid model for communications between two endpoints placed in two different SIP service-provider domains. SIP is also flexible, since SIP applications beyond the rendezvous function can reside either in the SIP networks in additional feature and media servers or in the endpoints. SIP endpoints are our focus in this memo.
SIPは、Rendezvousおよびセッション開始のためにRFC 3261で定義されています。通常の例は、2つの異なるSIPサービスプロバイダードメインに配置された2つのエンドポイント間の通信の台形モデルです。Rendezvous関数を超えたSIPアプリケーションは、追加機能およびメディアサーバーのSIPネットワークまたはエンドポイントのいずれかに存在する可能性があるため、SIPも柔軟です。SIPエンドポイントは、このメモの焦点です。
Since SIP has been invented, with much initial similarity between SIP and HTTP, the Web has evolved from a global access mechanism to static documents to a universal platform with rich interaction between the user and client. In most cases, the client is the browser, though recently dedicated Web desktop clients have emerged as well.
SIPが発明されて以来、SIPとHTTPの間に多くの初期類似性があるため、Webはグローバルアクセスメカニズムから静的ドキュメントに進化し、ユーザーとクライアントの間の豊富な相互作用を備えたユニバーサルプラットフォームに進化しました。ほとんどの場合、クライアントはブラウザですが、最近専用のWebデスクトップクライアントも登場しています。
The Web provides access to applications as well as to documents. It is beyond the scope of this memo to describe the application and network architectures of the Web. We will note, however, some of the new application and communication forms that have emerged on the Web as a result of a Darwinian evolution [30] rather than as a result of being defined in standards organizations. They are referred to as Rich Internet Applications.
Webは、アプリケーションとドキュメントへのアクセスを提供します。Webのアプリケーションとネットワークアーキテクチャを説明するのは、このメモの範囲を超えています。ただし、標準組織で定義された結果としてではなく、ダーウィンの進化[30]の結果としてWebで登場した新しいアプリケーションとコミュニケーションフォームの一部に注意してください。それらは豊富なインターネットアプリケーションと呼ばれます。
Examples of RIAs include social networks, blogs, wikis, web-based office and collaboration tools, as well as task-related apps for creating to-do lists, tracking time, combining geographic information with various applications (such as tracking exercise paths and recording the metrics), tracking airline flights, combining live video from events with results and comments, etc.
RIAの例には、ソーシャルネットワーク、ブログ、Wikis、Webベースのオフィス、コラボレーションツール、To Doリストの作成、追跡時間、地理情報とさまざまなアプリケーションの組み合わせ（運動パスの追跡や録音などのタスク関連アプリが含まれます。メトリック）、航空会社のフライトの追跡、イベントのライブビデオと結果やコメントなどを組み合わせて。
More information can be found at [31] and in the vast collection of books about RIAs.
詳細については、[31]とRIAに関する膨大な本のコレクションにあります。
RIAs have positioned the browser (and associated Web desktop applications) as the dominant platform for a large variety of applications. They are universal application platforms, independent of network location, operating system, processor, or display size.
RIASは、ブラウザ（および関連するWebデスクトップアプリケーション）を多種多様なアプリケーションの支配的なプラットフォームとして配置しています。それらは、ネットワークの場所、オペレーティングシステム、プロセッサ、またはディスプレイサイズとは無関係に、ユニバーサルアプリケーションプラットフォームです。
Behind the better-known Web applications are a wealth of new technologies that can enhance SIP-based communications, for example, the aggregation of data at runtime from several resources on the Internet. A variety of RIA components, such as found on interactive Web pages, can significantly improve the user experience of SIP-based communications. This is in contrast to the fixed interfaces found in most SIP user agents (UA), such as phones and desktop clients.
よく知られているWebアプリケーションの背後には、SIPベースの通信を強化できる豊富な新しいテクノロジーがあります。たとえば、インターネット上のいくつかのリソースからの実行時のデータの集約です。インタラクティブなWebページにあるようなさまざまなRIAコンポーネントは、SIPベースの通信のユーザーエクスペリエンスを大幅に改善できます。これは、電話やデスクトップクライアントなど、ほとんどのSIPユーザーエージェント（UA）に見られる固定インターフェイスとは対照的です。
The Web network and application architecture is very different from SIP service-provider networks at present, but the one point where they both meet is the end-user device of any shape: fixed or mobile.
Webネットワークとアプリケーションアーキテクチャは、現在SIPサービスプロバイダーネットワークとは大きく異なりますが、どちらも出会う1つのポイントは、固定またはモバイルの形状のエンドユーザーデバイスです。
The desire of SIP service providers to support new services in a scalable and flexible manner is incidentally easier to implement by the loose service coupling on the Web, as it is possible to characterize a service, or actually a mix of several service components (such as in a mash-up), with a URI. This is in contrast to network services registration being done by a central registrar. The Web architecture is also better suited for users to select and configure their applications and interaction mode with the client. The boundless variety of configurations of services and client settings on the Web is in contrast with the prepackaged services and fixed user-agent configurations in present SIP services.
SIPサービスプロバイダーがスケーラブルで柔軟な方法で新しいサービスをサポートしたいという欲求は、サービスを特徴付けることができるため、または実際にいくつかのサービスコンポーネントの組み合わせを特徴付けることができるため、Web上のゆるいサービス結合により偶然に実装しやすいことです（マッシュアップ）、URIで。これは、ネットワークサービス登録が中央レジストラによって行われているのとは対照的です。また、Webアーキテクチャは、ユーザーがクライアントとのアプリケーションとインタラクションモードを選択および構成するのに適しています。Web上のサービスとクライアントの設定の制定の無限の多様性は、現在のSIPサービスにおけるパッケージ化されたサービスと固定されたユーザーエージェント構成とは対照的です。
Last but not least, program execution locally on the client is faster if the interaction with servers across the network is minimized.
最後になりましたが、ネットワーク全体のサーバーとの相互作用が最小化されると、クライアントでのプログラムの実行が速くなります。
The motivation behind this memo is the potential of integrating SIP-based multimedia communications with access to RIAs on the Web. To mention a few scenarios: adding SIP- and RTP-based real-time communications to RIAs, integrating (from a user perspective) the SIP location service (not to be confused with geographic location services) with other desktop- and network-based geographic location services, using social networks as part of the contact list, etc.
このメモの背後にある動機は、SIPベースのマルチメディア通信をWeb上のRIASへのアクセスと統合する可能性です。いくつかのシナリオに言及するために：SIPおよびRTPベースのリアルタイム通信をRIASに追加し、（ユーザーの観点から）SIPロケーションサービス（地理的ロケーションサービスと混同しないでください）を他のデスクトップおよびネットワークベースの地理的サービスと統合しますソーシャルネットワークを連絡先リストの一部として使用する場所など。
In order to accomplish interoperability with the installed base of telephone networks of various kinds, integrating SIP communications into RIAs precludes, in our opinion, carrying legacy telephony features over to the Web. Interoperability between the Internet and telephone networks is best left to gateways that look to the Web as special endpoints serving large numbers of users. Plain one-to-one phone calls are already supported by Internet-to-telephony gateways. If added, PSTN (Public Switched Telephone Network) or ISDN telephony features must be exposed to Web users; visual Web display and interaction with the user is preferable to carrying the extremely complex SIP equivalents over into the Internet. On the Internet side of telephony gateways, simple SIP is all that needs to be deployed, in our opinion. Additional telephony features can be just another RIA hosted in the gateway. The market is the best indicator to show if such an effort is worthwhile to be productized.
さまざまな種類の電話ネットワークのインストールされたベースとの相互運用性を達成するために、SIP通信をRIASに統合し、私たちの意見では、レガシーテレフォニー機能をWebに持ち込みます。インターネットネットワークと電話ネットワーク間の相互運用性は、多数のユーザーにサービスを提供する特別なエンドポイントとしてWebに見えるゲートウェイに最適です。単純な1対1の電話は、インターネットから四面のゲートウェイによってすでにサポートされています。追加すると、PSTN（公開された電話ネットワーク）またはISDNテレフォニー機能をWebユーザーに公開する必要があります。視覚的なWebディスプレイとユーザーとのやり取りは、非常に複雑なSIP相当量をインターネットに持ち込むよりも望ましいです。テレフォニーゲートウェイのインターネット側では、私たちの意見では、シンプルなSIPが展開する必要があるすべてです。追加のテレフォニー機能は、ゲートウェイでホストされている別のRIAにすぎません。市場は、そのような努力が製品化される価値があるかどうかを示すのに最適な指標です。
Overloading simple SIP with telephony features is a non-objective, as detailed in Section 3.
セクション3で詳述されているように、テレフォニー機能を備えた単純なSIPの過負荷は非目的です。
This section aims to clarify the scope of applicability by considering what can be done better in the endpoints, what simple SIP for user agents can and cannot accomplish, and what is out of scope. We will use emergency calls as an example to illustrate these points on applicability. Emergency calls are also a good example for considering if and when SIP-plus-RIA applications could be used as emergency telephony enhancements or even replacements.
このセクションの目的は、エンドポイントで何がより良いことができるか、ユーザーエージェント向けの単純なSIPが達成できないもの、および範囲外のものを考慮することにより、適用性の範囲を明確にすることを目的としています。例として緊急電話を使用して、適用性に関するこれらのポイントを説明します。また、緊急通話は、SIP-Plus-RIAアプリケーションを緊急電話の強化または交換として使用できるかどうかを検討するための良い例です。
The main goal for SIP applications on the desktop or in the browser is to support the integration of SIP- and RTP-based real-time communications with RIAs. This assumes powerful endpoints, such as PC/laptop, smart mobile phones, or various dedicated devices.
デスクトップまたはブラウザでのSIPアプリケーションの主な目標は、RIAとのSIPおよびRTPベースのリアルタイム通信の統合をサポートすることです。これは、PC/ラップトップ、スマート携帯電話、またはさまざまな専用デバイスなどの強力なエンドポイントを想定しています。
Example of better functionality: emergency calls not limited to a Public Safety Access Point (PSAP), but extended to a medical service taking care of patients or elderly people.
より良い機能の例：緊急通話は公共安全アクセスポイント（PSAP）に限定されず、患者や高齢者の世話をする医療サービスに拡張されました。
In this example, besides alerting the right medical provider of the emergency, vital body-sign data and video can also be transmitted. In the opposite direction, the caller may get visual and audio information and instructions for instant self-help. In this scenario, there is no need to invoke a PSAP service. A dedicated device for such scenarios may actually have an emergency medical call button, though for telephone calls to a PSAP this is not recommended [14]. Powerful endpoints may also have various means to determine the geographic location of the caller and transmit it to the emergency care provider. In this and other examples, SIP voice may be a component of several other communications means, but not always the central one; some emergency communications and data transfer may actually be performed without voice, such as instances when the "caller" cannot speak for some reason.
この例では、緊急事態の適切な医療提供者に警告することに加えて、重要なボディサインデータとビデオも送信できます。反対の方向には、発信者は視覚的および音声情報と瞬時のセルフヘルプの指示を取得する場合があります。このシナリオでは、PSAPサービスを呼び出す必要はありません。このようなシナリオ用の専用デバイスには、実際には緊急医療コールボタンがある場合がありますが、PSAPへの電話ではこれは推奨されません[14]。強力なエンドポイントには、発信者の地理的位置を決定し、救急医療提供者に送信するさまざまな手段もあります。この例および他の例では、SIP音声は他のいくつかの通信手段のコンポーネントである可能性がありますが、常に中心的な通信手段ではありません。「発信者」が何らかの理由で話すことができない場合など、いくつかの緊急通信とデータ転送は実際に音声なしで実行される場合があります。
The focus of the memo is to define the baseline for simple SIP: the establishment of a one-to-one real-time multimedia communication session for presence, IM, voice, and video. Adequate security must also be provided; authentication and encryption for the media and for parts of the signaling should be done in a manner consistent with the routing of SIP messages.
メモの焦点は、シンプルなSIPのベースラインを定義することです。これは、プレゼンス、IM、音声、ビデオのための1対1のリアルタイムマルチメディア通信セッションの確立です。適切なセキュリティも提供する必要があります。メディアおよびシグナリングの一部の認証と暗号化は、SIPメッセージのルーティングと一致する方法で行う必要があります。
There are border cases where simple SIP may or may not accomplish some necessary legacy function. Example: an emergency call to a PSAP over the Internet may be supported using the SOS URN [15] and the LoST protocol [16] to determine where to route the call. If, however, emergency calls must be routed over the PSTN to a country-specific telephone number, the assistance of a SIP proxy and also of a SIP-PSTN gateway is required to recognize and route the emergency call. Depending on the local jurisdiction, emergency calls from a SIP UA may require other features that are beyond the scope of this memo.
単純なSIPが必要なレガシー機能を達成する場合と達成できない場合がある国境の場合があります。例：インターネット上のPSAPへの緊急通話は、SOS URN [15]とLost Protocol [16]を使用してサポートされ、コールのルーティングを決定することができます。ただし、PSTNを介して国固有の電話番号に緊急通話をルーティングする必要がある場合、SIPプロキシとSIP-PSTNゲートウェイの支援が緊急コールを認識してルーティングする必要があります。地元の管轄区域に応じて、SIP UAからの緊急電話には、このメモの範囲を超えた他の機能が必要になる場合があります。
The simple usage of SIP is applicable when avoiding the traditional voice-provider approaches for charging (or monetizing) that aim to provide, manage, and charge for what is referred to as services (not applications); some examples of such approaches to charging are listed here. Simple SIP means to avoid placing any functions in the network other than the rendezvous function of SIP. This includes avoiding:
SIPの単純な使用法は、サービスと呼ばれるもの（アプリケーションではなく）と呼ばれるものを提供、管理、請求する充電（または収益化）のために従来の音声プロバイダーアプローチを回避する場合に適用されます。このような充電へのアプローチの例をいくつかここにリストします。単純なSIPとは、SIPのランデブー関数以外の機能をネットワークに配置しないことを意味します。これには回避が含まれます。
o support of legacy telephony functions, such as emulating public-telephone-switch services and voice-only private branch exchanges.
o パブリックテレフォンスイッチサービスのエミュレートや音声専用のプライベートブランチ交換など、レガシーテレフォニー機能のサポート。
o SIP network architectures designed to support telephony-type network models. Examples include long chains of SIP proxies and feature servers (more than the two SIP servers shown in RFC 3261) that may be encountered inside and between closed Voice over IP (VoIP) networks and in-transit VoIP networks in between. Long chains of intermediaries of any type not only add complexity, they pose a security risk that increases with the number of SIP network elements. Complex server-based networks also make it more difficult to introduce new services. A special problem in SIP server chains is forking, which leads to the well-known problems of concurrency in computing; the so-called race conditions in telephony. This is amplified by redesigning the whole network every time there is a new SIP routing requirement.
o Telephonyタイプのネットワークモデルをサポートするように設計されたSIPネットワークアーキテクチャ。例には、SIPプロキシと機能サーバーの長いチェーン（RFC 3261に示されている2つのSIPサーバーを超える）が含まれます。これらは、IPオーバーIP（VOIP）ネットワークとその間に閉鎖内のVoIPネットワーク内および間に遭遇する可能性があります。あらゆるタイプの仲介者の長いチェーンは、複雑さを追加するだけでなく、SIPネットワーク要素の数とともに増加するセキュリティリスクをもたらします。複雑なサーバーベースのネットワークは、新しいサービスを導入することをより困難にしています。SIPサーバーチェーンの特別な問題はフォーキングです。これは、コンピューティングにおける同時性のよく知られている問題につながります。テレフォニーのいわゆる人種条件。これは、新しいSIPルーティング要件があるたびにネットワーク全体を再設計することにより増幅されます。
o support for legacy telephony models, such as identifying end-user devices for the purpose of differentiated charging by type of service or for charging for roaming between networks.
o サービスの種類による差別化された充電やネットワーク間のローミングの充電のために、エンドユーザーデバイスの識別など、レガシーテレフォニーモデルのサポート。
o policies and the associated policy servers and network elements for Quality of Service (QoS) to enforce service-rate-specific policies for real-time communications.
o リアルタイム通信のためのサービスレート固有のポリシーを実施するためのポリシーと関連するポリシーサーバーとネットワークサービス品質（QoS）。
o design considerations for SIP for compatibility with legacy telephony networks, traditional telephony services, and various telephone numbering plans. This pushes the responsibility of mapping the URI to telephone numbers to edge networks where the IP-PSTN gateway functions are performed. The handling of telephony-specific functions, such as early media, are also pushed to edge gateway networks. Other design considerations for interworking with the PSTN and 'looking like the PSTN' are also avoided.
o レガシーテレフォニーネットワーク、従来のテレフォニーサービス、およびさまざまな電話番号計画との互換性に関するSIPの設計上の考慮事項。これにより、URIを電話番号にマッピングする責任が、IP-PSTNゲートウェイ関数が実行されるエッジネットワークへのエッジネットワークへの責任を押し上げます。初期メディアなどのテレフォニー固有の機能の処理も、Edge Gatewayネットワークにプッシュされます。PSTNとの相互作用や「PSTNのように見える」という他の設計上の考慮事項も回避されます。
This list is not exhaustive, but conveys the concept of what to avoid when using SIP as a simpler protocol to understand and to implement.
このリストは網羅的なものではありませんが、SIPをより単純なプロトコルとして使用して実装するときに避けるべきことの概念を伝えます。
There are also some interesting borderline cases for what to avoid, such as Provisional Response Acknowledgements (PRACKs), specified in RFC 3262. PRACK is targeted for multi-hop SIP server networks and PSTN interworking, especially to assure reliable early media. PRACK can be delegated, albeit with some limitations to the SIP-PSTN gateway. PRACK does little to improve the user experience and has no relevance on true broadband networks with minimal SIP hop counts. Using PRACK may therefore be a decision best left to designers.
また、RFC 3262で指定された暫定的な応答承認（プラック）など、避けるべきものの興味深い境界線もいくつかあります。SIP-PSTNゲートウェイにはいくつかの制限がありますが、プラックは委任できます。Prackはユーザーエクスペリエンスを改善するためにほとんど機能しません。また、SIPホップカウントを最小限に抑えた真のブロードバンドネットワークには関連性がありません。したがって、Prackを使用することは、デザイナーに残された決定である可能性があります。
Another interesting example of a borderline case are the issues with SIP's Non-Invite transactions as discussed in RFC 4320 [17]. Long chains of SIP intermediaries complicate the handling of provisional responses and may create several problems, such as storms of late responses from forked SIP forwarding paths. We mentioned that long chains of SIP intermediaries are out of scope for simple SIP, but since designers may encounter various scenarios, even those they don't like, the decision to conform the user agent (UA) to RFC 4320 is best left to them.
境界線の別の興味深い例は、RFC 4320 [17]で説明したように、SIPの非インバイトトランザクションの問題です。SIP仲介者の長いチェーンは、暫定的な反応の取り扱いを複雑にし、Forked SIP転送パスからの遅い応答の嵐など、いくつかの問題を引き起こす可能性があります。SIP仲介者の長いチェーンは単純なSIPの範囲外であると述べましたが、デザイナーはさまざまなシナリオに遭遇する可能性があるため、嫌いなシナリオでも、ユーザーエージェント（UA）をRFC 4320に適合させるという決定が最適です。
The list of borderline cases is also not exhaustive and the above are only examples. So where is the borderline? We believe that SIP usage on the Internet, without any intermediaries designed to support closed VoIP networks, eliminates the borderline cases. Enterprise SIP networks are also most useful when designed to work with the Internet model in mind, by giving enterprise users the benefit of SIP-enhanced Web applications for productivity. Handling of SIP in enterprise firewalls is out of the scope of this memo.
境界線のリストも網羅的ではなく、上記は単なる例です。では、境界線はどこにありますか？閉じたVoIPネットワークをサポートするために設計された仲介者がいないことがないため、インターネット上でのSIP使用は、境界線のケースを排除すると考えています。Enterprise SIPネットワークは、エンタープライズユーザーにSIP強化Webアプリケーションの生産性を提供することで、インターネットモデルを念頭に置いて作業するように設計されている場合にも最も便利です。エンタープライズファイアウォールでのSIPの処理は、このメモの範囲外です。
Here is the minimal set of mandatory references to support the Internet-centric approach to SIP, outlined above. The minimal set of references defines simple SIP.
上記で概説したSIPへのインターネット中心のアプローチをサポートするための最小限の必須参照セットです。参照の最小セットは、単純なSIPを定義します。
The proposed change process [29] for SIP in the IETF RAI area will define the updated SIP core specification and thus reduce even more the required SIP standards for what is referred to here as simple SIP.
IETF RAIエリアのSIPの提案された変更プロセス[29]は、更新されたSIPコア仕様を定義し、ここで簡単なSIPと呼ばれるものに必要なSIP標準をさらに減らします。
RFC 3261 [1] is the core specification for SIP. The trapezoid model for SIP, found in RFC 3261, is only an example and a use case applicable to two service providers featuring an outgoing SIP proxy and an incoming SIP proxy in each domain respectively. However, SIP can also work in peer-to-peer (P2P) communications without SIP servers.
RFC 3261 [1]は、SIPのコア仕様です。RFC 3261にあるSIPの台形モデルは、それぞれ各ドメインに発信されるSIPプロキシと着信SIPプロキシを備えた2つのサービスプロバイダーに適用可能な例とユースケースのみです。ただし、SIPはSIPサーバーなしでピアツーピア（P2P）通信でも機能します。
SDP [2] is the standard format for the representation of media parameters, transport addresses, and other session data irrespective of the protocol used to transport the SDP data. SIP is one of the protocols used to transport SDP data, to enable the setting up of multimedia communication sessions. Other Internet application protocols use SDP as well.
SDP [2]は、SDPデータの輸送に使用されるプロトコルに関係なく、メディアパラメーター、輸送アドレス、およびその他のセッションデータを表現するための標準形式です。SIPは、マルチメディア通信セッションのセットアップを可能にするために、SDPデータの輸送に使用されるプロトコルの1つです。他のインターネットアプリケーションプロトコルもSDPを使用しています。
4.3. RFC 3264: "An Offer/Answer Model with Session Description Protocol (SDP)"
4.3. RFC 3264：「セッション説明プロトコル（SDP）を使用したオファー/回答モデル」
Though SDP has the capability to describe SIP sessions, how to arrive at a common description by two SIP endpoints requires a negotiation procedure to agree on common media codecs, along with IP addresses and ports where the media can be received. This negotiation procedure is specified in RFC 3264 [3]. As will be seen in Section 6, this negotiation is usually considerably complicated due to the existence of NAT between the SIP endpoints.
SDPにはSIPセッションを説明する機能がありますが、2つのSIPエンドポイントで共通の説明に到達する方法には、メディアを受信できるIPアドレスとポートとともに、一般的なメディアコーデックに同意する交渉手順が必要です。この交渉手順は、RFC 3264 [3]で指定されています。セクション6で見られるように、この交渉は通常、SIPエンドポイント間にNATが存在するため、かなり複雑です。
A SIP UA can convey its capability in the Contact header field, indicating if it can support presence, IM, audio, or video, and if the device is fixed, mobile, or other, such as the endpoint being an automaton (voice mail for example). Which SIP methods are supported may also be indicated as specified in RFC 3840 [4]. SIP registrars (SIP servers or the P2P SIP overlay) can be informed of endpoint capabilities. Missing capabilities can be displayed for the user by, for example, grayed out or missing icons.
SIP UAは、コンタクトヘッダーフィールドでその機能を伝えることができ、存在感、IM、オーディオ、またはビデオをサポートできるかどうかを示します。また、エンドポイントがオートマトンであるなど、デバイスが固定、モバイル、またはその他の場合（ボイスメール）例）。どのSIPメソッドがサポートされているかは、RFC 3840で指定されているように示される場合があります[4]。SIPレジストラ（SIPサーバーまたはP2P SIPオーバーレイ）には、エンドポイント機能を通知できます。不足している機能は、たとえば、グレー化されたアイコンや欠落しているアイコンによって、ユーザー向けに表示できます。
RFC 3263 [5] adds key clarifications to the base SIP specification in RFC 3261 by specifying how a SIP user agent (UA) or SIP server can determine with DNS queries not only the IP addresses of the target SIP servers, but also which SIP servers can support UDP or TCP transport, as required. TCP may be required to support secure SIP (SIPS) using Transport Layer Security (TLS) transport or when SIP messages are too large to fit into UDP packets without fragmentation. Successive DNS queries yield finer-grain location by providing NAPTR, SRV, and A type records. Note that finding a SIP server requires several successive DNS queries to access these records.
RFC 3263 [5]は、SIPユーザーエージェント（UA）またはSIPサーバーがターゲットSIPサーバーのIPアドレスだけでなく、どのSIPサーバーのDNSクエリで決定できるかを指定することにより、RFC 3261のベースSIP仕様に重要な明確化を追加します。必要に応じて、UDPまたはTCP輸送をサポートできます。TCPは、トランスポートレイヤーセキュリティ（TLS）トランスポートを使用して、またはSIPメッセージが大きすぎて断片化せずにUDPパケットに収まる場合は、Secure SIP（SIP）をサポートする必要があります。連続したDNSクエリは、NAPTR、SRV、およびタイプレコードを提供することにより、より細かい粒の位置を生成します。SIPサーバーを見つけるには、これらのレコードにアクセスするためにいくつかの連続したDNSクエリが必要であることに注意してください。
Locating SIP servers is also required for P2P SIP when a peer node wishes to communicate with a SIP UA outside its own P2P SIP overlay network.
ピアノードが独自のP2P SIPオーバーレイネットワークの外側のSIP UAと通信したい場合、P2P SIPにはSIPサーバーの配置も必要です。
RFC 3265 [6] provides an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. The most prominent event notifications are those used for presence, though SIP events are used for many other SIP services, some of which can be useful for simple SIP.
RFC 3265 [6]は、SIPノードが特定のイベントが発生したことを示すリモートノードから通知を要求できる拡張可能なフレームワークを提供します。SIPイベントは他の多くのSIPサービスに使用されていますが、最も顕著なイベント通知は存在に使用されているものです。その一部はSimple SIPに役立ちます。
RFC 3856 [7] defines the usage of SIP as a presence protocol and makes use of the SUBSCRIBE and NOTIFY methods for presence events. SIP location services already contain presence information in the form of registrations and, as such, can be reused to establish connectivity for subscriptions and notifications. This can enable either endpoints or servers to support rich applications based on presence.
RFC 3856 [7]は、SIPの使用をプレゼンスプロトコルとして定義し、登録イベントのサブスクライブおよび通知方法を使用します。SIPロケーションサービスには、すでに登録の形で存在情報が含まれているため、サブスクリプションと通知の接続を確立するために再利用できます。これにより、エンドポイントまたはサーバーのいずれかが存在に基づいてリッチアプリケーションをサポートできるようになります。
RFC 3863 [8] defines the Presence Information Data Format (PIDF) and the media type "application/pidf+xml" to represent the XML MIME entity for PIDF. PIDF is used by SIP to carry presence information.
RFC 3863 [8]は、PIDFのXML MIMEエンティティを表すために、存在情報データ形式（PIDF）とメディアタイプ「アプリケーション/PIDF XML」を定義します。PIDFは、SIPで存在情報を伝達するために使用されます。
The SIP extension for IM in RFC 3428 [9] consists in the MESSAGE method (defined in RFC 3428) only for the pager model of IM, based on the assumption that an IM conversation state exists in the client interface in the endpoints or in the mind of the users.
RFC 3428 [9]のIMのSIP拡張は、IMのページャーモデルに対してのみメッセージメソッド（RFC 3428で定義されています）で構成されています。ユーザーの心。
RFC 4474 [10] defines (1) an identity header and (2) an identity info header for SIP requests that carry, respectively, the signature of the issuer over parts of the SIP request and the signed identity information. The signature includes the FROM header and the identity of the sender. The associated identity info header identifies the sender of the SIP request, such as INVITE. The issuer of the signature can present their certificate as well. It is assumed the issuer may be the domain owner. Strong authentication is thus provided for SIP requests. Authentication for SIP responses is not defined in this document.
RFC 4474 [10]は、（1）IDヘッダーを定義し、（2）SIPリクエストの一部と署名されたID情報を介した発行者の署名をそれぞれ伝えるSIPリクエストのID情報ヘッダーを定義します。署名には、From HeaderとSenderの身元が含まれます。関連するID情報ヘッダーは、InviteなどのSIP要求の送信者を識別します。署名の発行者も証明書を提示できます。発行者がドメインの所有者である可能性があると想定されています。したがって、SIPリクエストには強力な認証が提供されます。SIP応答の認証は、このドキュメントでは定義されていません。
RFC 3581 [11] specifies an extension to SIP called "rport" so that responses are sent back to the source IP address and port from which the request originated. This correction to RFC 3261 is helpful for NAT traversal, debugging, and support of multi-homed hosts.
RFC 3581 [11]は、「rport」と呼ばれるSIPの拡張機能を指定して、応答がソースIPアドレスとリクエストが発生したポートに送信されるようにします。RFC 3261へのこの修正は、NATトラバーサル、デバッグ、マルチホームホストのサポートに役立ちます。
Several of the above are being updated to benefit from the experience of large deployments and frequent interoperability testing. We recommend readers to constantly check for revisions. One update example is "Correct Transaction Handling for 200 Responses to the Session Initiation Protocol INVITE Requests" [18]. This is an update to RFC 3261; the added security risk for misbehaving SIP UAs is handled in the forwarding SIP proxy.
上記のいくつかは、大規模な展開と頻繁な相互運用性テストの経験の恩恵を受けるために更新されています。読者は常に改訂を確認することをお勧めします。更新の例の1つは、「セッション開始プロトコルへの200個の応答の正しいトランザクション処理のための正しいトランザクション処理」です[18]。これはRFC 3261の更新です。SIP UASを誤動作するための追加のセキュリティリスクは、転送SIPプロキシで処理されます。
Although the present adoption of SIP is mainly due to telephony applications, its roots are in the Web and it has initial similarity to HTTP. As a result, SIP may play other roles in adequately powerful endpoints (their number keeps increasing with Moore's law). SIP-based multimedia communications may be linked with various other applications on the Web. Either some non-SIP application or the communication feature may be perceived as the primary usage. An example is mixing SIP-based real-time communications with some Web content of high interest to the user.
現在のSIPの採用は主にテレフォニーアプリケーションによるものですが、そのルーツはWebにあり、HTTPと初期の類似性があります。その結果、SIPは、適切に強力なエンドポイントで他の役割を果たす可能性があります（ムーアの法律ではその数は増加し続けます）。SIPベースのマルチメディア通信は、Web上の他のさまざまなアプリケーションとリンクできます。一部の非SIPアプリケーションまたは通信機能のいずれかが、主要な使用法として認識される場合があります。例としては、SIPベースのリアルタイム通信とユーザーにとって高い関心のあるWebコンテンツを混合することです。
Examples:
例：
1. In a conversation between a consumer and the contact center, a Web conference can be invoked to present to the user buying options or help information. This information can make use of mashups to combine real-time data from various sources on the Web.
1. 消費者とコンタクトセンターの間の会話では、Web会議を呼び出して、ユーザーの購入オプションや情報を支援するために呼び出されます。この情報は、Mashupsを利用して、Web上のさまざまなソースからのリアルタイムデータを組み合わせることができます。
2. In a social network, multimedia conversations combined with Web mashups can be invoked, thus strengthening the bond between its members.
2. ソーシャルネットワークでは、Webマッシュアップと組み合わせたマルチメディアの会話を呼び出すことができ、メンバー間の絆を強化することができます。
3. Conversations can be invoked while watching some events on the Web in real time. However, the main beneficiary in this case may be the Web site, since the conversation can prolong the time for users watching that Web site.
3. ウェブ上でいくつかのイベントをリアルタイムで視聴しているときに、会話を呼び出すことができます。ただし、この場合の主な受益者はWebサイトである可能性があります。これは、会話がユーザーがそのWebサイトを視聴する時間を延長する可能性があるためです。
This shows the value of combining RIAs with SIP-based communications.
これは、RIAをSIPベースの通信と組み合わせることの価値を示しています。
It is a matter for the end user's judgment whether the Web content or the associated communication capability is more important, or if a mix of both is most attractive.
Webコンテンツまたは関連する通信機能がより重要であるかどうか、または両方の組み合わせが最も魅力的であるかどうかは、エンドユーザーの判断の問題です。
Example: a Web-based enterprise directory where employees can find a wealth of data. Adding SIP multimedia communications to the enterprise directory to call someone (if online and not too busy) enhances its usefulness, but is not critical to the directory.
例：従業員が豊富なデータを見つけることができるWebベースのエンタープライズディレクトリ。SIPマルチメディア通信をエンタープライズディレクトリに追加して、誰かを呼び出す（オンラインで忙しすぎない場合）、その有用性を高めますが、ディレクトリにとって重要ではありません。
SIP applications in the endpoints can, however, accomplish most telephony functions as well. This has been amply documented in SIP-related work in the IETF, such as:
ただし、エンドポイントのSIPアプリケーションは、ほとんどのテレフォニー機能も達成できます。これは、次のようなIETFでのSIP関連作業で十分に文書化されています。
o "A Call Control and Multi-party usage framework for SIP" [19] presents a large assortment of telephony applications where the call control resides in the participating endpoints that use the peer-to-peer feature invocation model. The peer-to-peer design and its principles are based on multiparty call control.
o 「SIPのコールコントロールとマルチパーティの使用フレームワーク」[19]は、ピアツーピア機能の呼び出しモデルを使用する参加エンドポイントにコールコントロールが存在する大規模なテレフォニーアプリケーションを提示します。ピアツーピアのデザインとその原則は、マルチパーティコールコントロールに基づいています。
o "Session Initiation Protocol Service Examples" [20] contains a collection of SIP call flows for traditional telephony, many of which require no server support for the respective features. The SIP service examples for telephony are extremely useful since they illustrate in detail the concepts and applications supported by the core simple SIP references.
o 「セッション開始プロトコルサービスの例」[20]には、従来のテレフォニー用のSIPコールフローのコレクションが含まれています。その多くは、それぞれの機能のサーバーサポートを必要としません。テレフォニーのSIPサービスの例は、コアシンプルなSIP参照によってサポートされている概念とアプリケーションを詳細に説明するため、非常に便利です。
In conclusion, SIP applications in the endpoints can support both a mix of real-time communications with new rich Internet applications and traditional telephony features as well.
結論として、エンドポイントのSIPアプリケーションは、新しいリッチインターネットアプリケーションとのリアルタイム通信と従来のテレフォニー機能の両方を組み合わせてサポートできます。
SIP devices behind one or more NATs are, at present, the rule rather than the exception.
1つ以上のNATの後ろのSIPデバイスは、現在、例外ではなくルールです。
"Best Current Practices for NAT Traversal for SIP" [22] comprehensively summarizes the use of STUN, TURN, and ICE, and provides a definitive set of 'Best Common Practices' to demonstrate the traversal of SIP and its associated RTP media packets through NAT devices.
「SIPのNATトラバーサルの最良の現在のプラクティス」[22]は、スタン、ターン、アイスの使用を包括的に要約し、NATを介したSIPとその関連RTPメディアパケットのトラバーサルを実証するために、「最高の共通プラクティス」の決定的なセットを提供します。デバイス。
The use of ICE has been developed mainly for SIP. Other proposals, such as NICE (generic for non-SIP) and "D-ICE" for Real Time Streaming Protocol (RTSP) streaming media, have also been proposed. Internet games have different NAT traversal techniques of their own. This list is not exhaustive and such approaches are based on different NAT traversal protocols for each application protocol, separately.
氷の使用は、主にSIP用に開発されています。リアルタイムストリーミングプロトコル（RTSP）ストリーミングメディア向けのNICE（非SIPの汎用）や「D-ICE」などのその他の提案も提案されています。インターネットゲームには、独自のNATトラバーサルテクニックが異なります。このリストは網羅的ではなく、そのようなアプローチは、各アプリケーションプロトコルの異なるNATトラバーサルプロトコルに個別に基づいています。
A general, non-application-protocol-specific approach for NAT traversal is therefore highly desirable.
したがって、NATトラバーサルに対する一般的な非アプリケーションプロトコル固有のアプローチは非常に望ましいです。
One approach for NAT traversal that is generic and applicable for all application protocols is to deploy the Host Identity Protocol (HIP) and solve NAT traversal only once, at the HIP level. HIP has many other useful features (such as support for the IPv6 transition in endpoints, mobility, and multihoming) that are beyond the scope of this paper. "Basic HIP Extensions for Traversal of Network Address Translators" [23] provides an extensive coverage of the use of HIP for NAT traversal.
一般的で、すべてのアプリケーションプロトコルに適用可能なNATトラバーサルの1つのアプローチは、ホストIDプロトコル（HIP）を展開し、股関節レベルでNATトラバーサルを1回だけ解くことです。HIPには、このペーパーの範囲を超えた他の多くの有用な機能（エンドポイント、モビリティ、マルチホームのIPv6遷移のサポートなど）があります。「ネットワークアドレス翻訳者のトラバーサルのための基本的な股関節拡張」[23]は、NATトラバーサルのための股関節の使用に関する広範なカバレッジを提供します。
Using HIP-enabled endpoints can provide the functions required for NAT traversal [24] for all applications, for both IPv4 and IPv6. HIP can thus simplify the SIP UA since it takes away the burden of NAT traversal from the SIP UA and moves it to the HIP protocol module in the endpoint.
股関節対応のエンドポイントを使用すると、すべてのアプリケーション、IPv4とIPv6の両方に対して、NATトラバーサル[24]に必要な関数を提供できます。したがって、股関節は、SIP UAからのNATトラバーサルの負担を奪い、エンドポイントの股関節プロトコルモジュールに移動するため、SIP UAを簡素化できます。
All protocols discussed in this paper have their own specific security requirements that MUST be considered. The special security considerations for SIP signaling security and RTP media security are discussed here.
この論文で説明するすべてのプロトコルには、考慮しなければならない独自の特定のセキュリティ要件があります。SIPシグナリングセキュリティとRTPメディアセキュリティに関する特別なセキュリティに関する考慮事項については、ここで説明します。
SIP security has two main parts: transport security and identity.
SIPセキュリティには、輸送セキュリティとアイデンティティの2つの主要な部分があります。
o Transport security for SIP is specified in RFC 3261. Secure SIP has the notation SIPS in the request URI and uses TLS over TCP. Note that SIP over UDP cannot be secured in this way. Transport security works only hop by hop. Specifying SIPS requires the user to trust all intermediate servers and no end-to-end media encryption is assumed. There is no insurance for misbehaving intermediaries in the path. SIPS is therefore really adequate only in single-hop scenarios.
o SIPの輸送セキュリティはRFC 3261で指定されています。セキュアSIPには、リクエストURIに表記SIPがあり、TCPを介してTLSを使用しています。UDP上のSIPは、この方法で保護できないことに注意してください。輸送セキュリティはホップのみでホップのみです。SIPを指定するには、ユーザーがすべての中間サーバーを信頼する必要があり、エンドツーエンドのメディア暗号化は想定されません。パスに誤動作仲介者に対する保険はありません。したがって、SIPはシングルホップシナリオでのみ非常に適切です。
o RFC 4474, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", which is mentioned previously, specifies the use of certificates for secure identification of the parties involved in SIP signaling requests.
o RFC 4474、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」は、前述のことで、SIPシグナル伝達要求に関与する当事者の安全な識別のための証明書の使用を指定しています。
o The Datagram Transport Layer Security (DTLS) specified in RFC 4347 [25] has wide applicability for other applications that require UDP transport. DTLS has been designed to have maximum commonality with TLS, yet does not require TCP transport and works over UDP. The DTLS-SRTP (Secure Realtime Transport Protocol) Framework [26] can support encrypted communications between endpoints using self-signed certificates whose fingerprints are exchanged over an integrity-protected SIP signaling channel. The SRTP master secret is derived using the DTLS exchange as described in [27].
o RFC 4347 [25]で指定されたデータグラムトランスポートレイヤーセキュリティ（DTL）は、UDP輸送を必要とする他のアプリケーションに幅広い適用性を備えています。DTLSは、TLSと最大の共通性を持つように設計されていますが、TCP輸送を必要とせず、UDPを介して動作します。DTLS-SRTP（セキュアリアルタイムトランスポートプロトコル）フレームワーク[26]は、整合性保護されたSIPシグナリングチャネルを介して指紋が交換される自己署名証明書を使用して、エンドポイント間の暗号化された通信をサポートできます。SRTPマスターシークレットは、[27]に記載されているDTLS Exchangeを使用して導出されます。
o ZRTP [28] provides key agreement for SRTP for multimedia communication with voice without depending on SIP signaling, though it can utilize an integrity-protected SIP signaling path for authentication. ZRTP does not require the use of certificates or any Public Key Infrastructure (PKI). ZRTP provides best-effort SRTP encryption without any additional SIP extensions.
o ZRTP [28]は、SIPシグナル伝達に依存することなく音声とのマルチメディア通信のためのSRTPの重要な合意を提供しますが、認証のために整合性保護されたSIPシグナリングパスを利用できます。ZRTPは、証明書または公開キーインフラストラクチャ（PKI）の使用を必要としません。ZRTPは、追加のSIP拡張機能なしで、Best-Effort SRTP暗号化を提供します。
The authors would like to thank Cullen Jennings, Ralph Droms, and Adrian Farrel for helpful comments in the most recent stage of this memo.
著者は、このメモの最新の段階で有益なコメントをしてくれたCullen Jennings、Ralph Droms、およびAdrian Farrelに感謝したいと思います。
Special thanks are due to Paul Kyzivat for challenging the authors to clarify the role of telephony network gateways and also to Keith Drage for challenging them to discuss the use of emergency calls using simple SIP.
著者に電話ネットワークゲートウェイの役割を明確にするよう著者に挑戦してくれたポール・キジバットと、単純なSIPを使用して緊急通話の使用について議論するように挑戦してくれたキースドレイジに感謝します。
Robert Sparks has pointed to some missing references, which we have added.
ロバート・スパークスは、いくつかの欠落している参照を指摘しましたが、それを追加しました。
The authors would also like to thank Jiri Kuthan, Adrian Georgescu, and others for the detailed discussion on the SIPPING WG list. As a result, we have added clarification of what simple SIP can do, what it does not aim to do, and some scenarios in between. We would also like to thank Wilhelm Wimmreuter for the detailed review of the initial draft and to Arjun Roychaudhury for the comments regarding the need to clarify the difference between network-based services and endpoint applications.
著者はまた、ジリ・クタン、エイドリアン・ジョルジュク、その他の人々に、すすり泣きのWGリストに関する詳細な議論に感謝します。その結果、Simple SIPができること、それが目的としていないこと、およびその間にいくつかのシナリオを明確にしました。また、最初のドラフトの詳細なレビューについてWilhelm Wimmreuterに感謝し、Arjun Roychaudhuryに、ネットワークベースのサービスとエンドポイントアプリケーションの違いを明確にする必要性に関するコメントについても感謝します。
[1] 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.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INITIATION Protocol」、RFC 3261、2002年6月。
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[2] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[4] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[4] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[5] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）：SIPサーバーの位置」、RFC 3263、2002年6月。
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[6] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[7] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[7] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[8] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[8] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（PIDF）」、RFC 3863、2004年8月。
[9] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[9] Campbell、B.、Ed。、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「インスタントメッセージング用のセッション開始プロトコル（SIP）拡張」、RFC 3428、2002年12月。
[10] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[10] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[11] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", RFC 3581, August 2003.
[11] Rosenberg、J。およびH. Schulzrinne、「対称応答ルーティングのセッション開始プロトコル（SIP）の拡張」、RFC 3581、2003年8月。
[12] Rosenberg, J., "A Hitchhiker's Guide to the Session Initiation Protocol (SIP)", RFC 5411, February 2009.
[12] Rosenberg、J。、「セッション開始プロトコル（SIP）のヒッチハイカーガイド」、RFC 5411、2009年2月。
[13] Ohlmeier, N., "VoIP RFC Watch", http://rfc3261.net/.
[13] Ohlmeier、N。、「Voip RFC Watch」、http://rfc3261.net/。
[14] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, July 2009.
[14] Rosen、B。およびJ. Polk、「緊急通話を支援するコミュニケーションサービスの最良の現在の実践」、2009年7月、進行中の作業。
[15] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[15] Schulzrinne、H。、「緊急およびその他の有名なサービスのためのユニフォームリソース名（URN）」、RFC 5031、2008年1月。
[16] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[16] Hardie、T.、Newton、A.、Schulzrinne、H。、およびH. Tschofenig、「Lost：A Location-s-Service Translation Protocol」、RFC 5222、2008年8月。
[17] Sparks, R., "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4320, January 2006.
[17] Sparks、R。、「セッション開始プロトコル（SIP）非インバイトトランザクションで特定された問題に対処するアクション」、RFC 4320、2006年1月。
[18] Sparks, R. and T. Zourzouvillys, "Correct Transaction Handling for 200 Responses to Session Initiation Protocol INVITE Requests", Work in Progress, July 2009.
[18] Sparks、R。and T. Zourzouvillys、「セッション開始プロトコルの招待リクエストに対する200の応答の正しいトランザクション処理」、2009年7月の作業。
[19] Mahy, R., Sparks, R., Rosenberg, J., Petrie, D., and A. Johnson, "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Work in Progress, March 2009.
[19] Mahy、R.、Sparks、R.、Rosenberg、J.、Petrie、D。、およびA. Johnson、「セッション開始プロトコル（SIP）のコールコントロールとマルチパーティの使用フレームワーク」、進行中の作業、3月2009年。
[20] Johnston, A., Ed., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008.
[20] Johnston、A.、Ed。、Sparks、R.、Cunningham、C.、Donovan、S.、およびK. Summers、「セッション開始プロトコルサービスの例」、BCP 144、RFC 5359、2008年10月。
[22] Boulton, C., Rosenberg, J., Camarillo, G. and F. Audet, "Best Current Practices for NAT Traversal for Client-Server SIP", Work in Progress, September 2008.
[22] Boulton、C.、Rosenberg、J.、Camarillo、G。、およびF. Audet、「クライアントサーバーSIPのNat Traversalの最良の現在のプラクティス」、2008年9月、進行中の作業。
[23] Komu, M., Henderson, T., Tschofenig, H., Melen, J. and A. Keraenen, "Basic HIP Extensions for Traversal of Network Address Translators", Work in Progress, June 2009.
[23] Komu、M.、Henderson、T.、Tschofenig、H.、Melen、J。、およびA. Keraenen、「ネットワークアドレス翻訳者の横断のための基本的な股関節拡張」、2009年6月の作業。
[24] Moskowitz, R., "HIP Experimentation using Teredo", July 2008, http://www.ietf.org/proceedings/08jul/slides/HIPRG-3.pdf.
[24] Moskowitz、R。、「Teredoを使用したHIP実験」、2008年7月、http：//www.ietf.org/proceedings/08jul/slides/hiprg-3.pdf。
[25] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[25] Rescorla、E。およびN. Modadugu、「データグラム輸送層セキュリティ」、RFC 4347、2006年4月。
[26] Fischl, J., Tschofenig, H. and E. Rescorla, "Framework for Establishing an SRTP Security Context using DTLS", Work in Progress, March 2009.
[26] Fischl、J.、Tschofenig、H。、およびE. Rescorla、「DTLSを使用してSRTPセキュリティコンテキストを確立するためのフレームワーク」、2009年3月、Work in Progress。
[27] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", Work in Progress, February 2009.
[27] McGrew、D。およびE. Rescorla、「データグラムトランスポートレイヤーセキュリティ（DTLS）拡張機能リアルタイム輸送プロトコル（SRTP）のキーを確立する」、2009年2月の作業進行中。
[28] Zimmerman, P., Johnston, A. and J. Callas, "ZRTP: Media Path Key Agreement for Secure RTP", Work in Progress, March 2009
[28] Zimmerman、P.、Johnston、A。、およびJ. Callas、「ZRTP：Secure RTPのメディアパスキー契約」、2009年3月、進行中の作業
[29] Peterson, J., Jennings, C. and R. Sparks, "Change Process for the Session Initiation Protocol (SIP)", Work in Progress, July 2009.
[29] Peterson、J.、Jennings、C。and R. Sparks、「セッション開始プロトコル（SIP）の変化プロセス」、2009年7月の作業。
[30] Raman, T.V., "Toward 2 exp(W), Beyond Web 2.0", Communications of the ACM, Vol. 52, No.2, p. 52-59, February 2009.
[30] Raman、T.V。、「2 exp（w）、Beyond Web 2.0」、ACMの通信、Vol。52、No.2、p。52-59、2009年2月。
[31] Wikipedia, "Rich Internet application", http://en.wikipedia.org/wiki/Rich_Internet_Applications.
[31] ウィキペディア、「リッチインターネットアプリケーション」、http：//en.wikipedia.org/wiki/rich_internet_applications。
Authors' Addresses
著者のアドレス
Henry Sinnreich Adobe Systems, Inc. 601 Townsend Street, San Francisco, CA 94103, USA
Henry Sinnreich Adobe Systems、Inc。601 Townsend Street、San Francisco、CA 94103、USA
EMail: henrys@adobe.com
Alan Johnston Avaya Saint Louis, MO, USA
アラン・ジョンストン・アヴァヤ・セント・ルイス、ミズーリ州、米国
EMail: alan@sipstation.com
Eunsoo Shim Avaya Labs Research 233 Mount Airy Road Basking Ridge, NJ 07920 USA
Eunsoo Shim Avaya Labs Research 233 Mount Airy Road Basking Ridge、NJ 07920 USA
EMail: eunsooshim@gmail.com
Kundan Singh Columbia University Alumni 1214 Amsterdam Ave., MC0401 New York, NY, USA
Kundan Singh Columbia University Alumni 1214 Amsterdam Ave.、MC0401 New York、NY、USA
EMail: kns10@cs.columbia.edu