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
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.
インターネット中心の使用方法については、プレゼンスやIM、音声/ビデオ通信のためのSIP-必要な基準の数は、唯一のランデブーとSIPのセッション開始機能を使用して公開されているものよりも大幅に小さくすることができます。簡略化は、テレフォニーのエミュレーションとインテリジェントネットワークのそのモデルを避けることによって達成されます。 「シンプルな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.
約11まで、およそ100現在から、まだ成長している - SIPのためのこのアプローチは、遵守することと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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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ネットワーク、中にリアルタイムマルチメディア通信のための世界標準となっています。この成功のコストは、このようなネットワークのための様々な要求に対応するために、複雑で継続的な増加となっています。同時に、ワールド・ワイド・ウェブは、ブラウザとデスクトップの両方で、リッチインターネットアプリケーション（RIA）の無限のさまざまなプラットフォームとなっています。 SIPは、RIAのために有用であるためには、不必要な複雑さを追加し、従来の音声サービスプロバイダのための要件は、ゲートウェイエンドポイントを電話通信するためのインターワーキングを委任することによって回避することができます。 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:
（CS）は、SIPまたはピア・ツー・ピア（P2P）ランデブー機能があり、いくつかの理由は、エンドポイントでのほとんどまたはすべてのSIPアプリケーションを配置するために、Webサービスの観点から、あるだけのクライアント・サーバを使用します。
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のと容易に混合すること、したがって、スケーラブルで柔軟な方法で新しいサービスを提供するサービスプロバイダーを有効にすることができます。 RIAのでSIPアプリケーションを混合することも大幅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.
このドキュメントの「シンプルなSIPは、」SIP、音声、ビデオ、基本的なプレゼンス、インスタントメッセージング、およびまた、セキュリティの唯一のランデブーとセッション・セットアップ機能をサポートするために必要なSIP機能を指します。シンプルなSIPは、基本的なマルチメディア、リアルタイム通信「コール」を提供することに焦点を当てています。これは、ポイントツーポイントと様々な会議アプリケーションのためのプレゼンス、インスタントメッセージング、音声、およびビデオを含んでいます。一つまたは追加のサーバーの非常に小さな数を設けてもよいです。例えば、ボイスメールサーバは、呼び出し先が応答しないか、ボイスメールをチェックする場合は、ボイスメールに単純な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.
エンドポイントでのアプリケーションは、基本的な通信を確立したら、それはそれまでのユーザーが選択した利用可能な機能をサポートすることです。本論文では、このようなシナリオを対象としています。電話では、ユーザとサービスプロバイダへの値のほとんどは似シグナリングすることによって追加されます。これとは対照的に、Web上で、RIAのは価値のほとんどを追加します。エンドポイントでの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のためのコアとしてここに記載されているおおよそ11にSIP標準の数を制限します。この記事の執筆時点では、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.
このメモは、コアSIPプロトコルよりも多くを知っているか理解する必要から、Webアプリケーション開発者を保護することを目指しています。参照の合計数を最小限に抑える、そのようなエンドポイントに電話サービスを提供するための例として、NATトラバーサル、およびセキュリティなどの他の関連するトピックを含むされています。参照論文は、しかし、これらの知識リソースへのエントリポイントです。 SIPトピックの詳細なリスト、特に電話での関心のある読者は、RFC 5411 [12]、「SIPにAヒッチハイカーのガイド」の広範なリストでここに短いリストをフォローアップすることができます。ガイドでは、ほとんどを理解するための140以上の参照を持って、すべてではないが、他の場所IETFとにおけるSIPの公表機能。自動的にSIP関連のRFC [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対応エンドポイントにホスト識別プロトコル（HIP）を使用しての潜在的なオプションが与えられ、シンプルなSIPは、ここに挙げたもの以外の任意の規格を必要としなくてもよいです。セクション4で説明したようにHIPに代わるものは、そのようなSTUN（NATを介してUDPプロトコルの簡易トラバーサル）、TURN（トラバーサルリレー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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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は、ランデブー、セッション開始のためにRFC 3261で定義されています。通常の例では、2つの異なるSIPサービスプロバイダードメインに配置された2つのエンドポイント間の通信のための台形モデルです。 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デスクトップクライアントは、同様に浮上しているものの、ブラウザです。
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のの例としては、このような追跡運動パスや記録など様々なアプリケーション（と地理情報を組み合わせ、のto-doリストを作成する時間を追跡するためのソーシャルネットワーク、ブログ、Wiki、Webベースのオフィスとのコラボレーションツールだけでなく、タスク関連のアプリを含めますメトリクス）、などの結果やコメント、とのイベントからのライブ映像を組み合わせて、航空会社のフライトを追跡します
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.
RIAのアプリケーションの多種多様のための支配的なプラットフォームとしてブラウザ（及び関連するウェブデスクトップアプリケーション）を配置しています。彼らは、ネットワークの場所、オペレーティングシステム、プロセッサ、または表示サイズとは無関係に汎用アプリケーション・プラットフォームです。
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ベースの通信を高めることができる新技術の豊富です。 RIAの種々の成分は、インタラクティブなWebページで見られるような、大幅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.
ウェブ・ネットワークとアプリケーション・アーキテクチャは、現在SIPサービスプロバイダーネットワークから非常に異なっているが、それらの両方ミート一点は、任意の形状のエンドユーザ装置であって、固定または移動。
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.
このメモの背後にある動機は、Web上でのRIAへのアクセス権を持つSIPベースのマルチメディア通信を統合する可能性があります。 、RIAのにSIPベースとRTPベースのリアルタイム通信を追加すること（ユーザの観点から）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通信を統合し、様々な種類の電話網のインストールベースとの相互運用性を達成するためにWebにオーバーしています。インターネットと電話のネットワーク間の相互運用性は、最良の多数のユーザーにサービスを提供する特殊なエンドポイントとしてWebに見えるゲートウェイに残されています。平野一対一の電話は、すでにインターネットへのテレフォニーゲートウェイによってサポートされています。追加した場合は、PSTN（公衆交換電話網）またはISDNのテレフォニー機能は、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-プラス-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 /ノート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.
プレゼンス、IM、音声、およびビデオのための一対一のリアルタイムマルチメディア通信セッションの確立：メモの焦点は、単純なSIPのベースラインを定義することです。十分なセキュリティも提供されなければなりません。メディアおよびシグナリングの部品のための認証および暗号化は、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]及び失われたプロトコル[16]：実施例。しかし、緊急呼び出しは各国固有の電話番号にPSTNを介してルーティングする必要がある場合は、SIP-PSTNゲートウェイのSIPプロキシの支援とも緊急コールを認識し、ルートが必要です。地元の管轄区域によっては、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テレフォニー型ネットワークモデルをサポートするように設計されたネットワークアーキテクチャをSIP。例としては、SIPプロキシおよび内部に発生する可能性があります（RFC 3261に示されている2台のSIPサーバよりも多くの）機能サーバのと（VoIP）のネットワークとの間で輸送中のVoIPネットワークIP経由閉じ音声との間に長い鎖を含みます。いずれのタイプではないだけの仲介のロングチェーンが複雑さを追加し、彼らは、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.
従来の電話網、従来の電話サービス、および様々な電話番号計画との互換性のためのSIPのためのOの設計上の考慮事項。これは、IP-PSTNゲートウェイ機能が実行されるネットワークのエッジに番号に電話するURIをマッピングする責任を押します。このようなアーリーメディアとして電話固有の機能の取り扱いは、またエッジ・ゲートウェイ・ネットワークにプッシュされます。 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.
こうした暫定応答謝辞（PRACKs）として避ける何のためにいくつかの興味深い境界例は、もあり、RFCで指定された3262. PRACKは、信頼性の高い初期メディアを確保するために、特に、マルチホップSIPサーバ・ネットワークとPSTNインターワーキングを対象としています。 PRACKは、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仲介の長い鎖は、暫定応答の取り扱いを複雑にして、このようなフォークSIPの転送パスから後半の応答の嵐のようにいくつかの問題を作成することがあります。私たちは、SIP仲介の長い鎖が、単純なSIPのスコープ外であることを述べたが、設計者がさまざまなシナリオが発生する可能性があるため、も、彼らは好きではないものは、RFC 4320にユーザーエージェント（UA）に準拠する決定は、最高の彼らに残されています。
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.
境界線例リストも網羅的なものではなく、上記は一例です。だからここで境界線がありますか？私たちは、インターネット上のSIPの使用量は、閉じられたVoIPネットワークをサポートするように設計された任意の仲介なしに、境界線のケースを排除することを信じています。エンタープライズ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データを転送するために使用されるプロトコルの一つです。他のインターネットアプリケーションプロトコルは、同様にSDPを使用しています。
4.3. : "An Offer/Answer Model with Session Description Protocol (SDP)"
4.3. ：「セッション記述プロトコル（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の存在に通常かなり複雑です。
4.4. : "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)"
4.4. ：「セッション開始プロトコル（SIP）でユーザエージェントの能力を示します」
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が示す、Contactヘッダフィールドにその能力を伝えることができ、IM、音声、ビデオ、およびデバイスは、エンドポイントがオートマトン（ボイスメールのためのものとして、移動、または他の固定されている場合例）。 RFC 3840で指定されたSIP方法も示すことができるサポートされている[4]。 SIPレジストラ（SIPサーバやP2P SIPオーバーレイ）は、エンドポイントの能力を知ることができます。不足している機能は、例えば、グレーアウトやアイコンの欠落により、ユーザに表示することができます。
4.5. : "Session Initiation Protocol (SIP): Locating SIP Servers"
4.5. ： "セッション開始プロトコル（SIP）：ロケ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サーバはDNSクエリだけでなく、ターゲットSIPサーバのIPアドレスだけでなく、SIPサーバと決定することができる方法を指定することによって、RFC 3261におけるベースSIP仕様にキー明確化を追加します必要に応じて、UDPまたはTCPトランスポートをサポートすることができます。 TCPはトランスポート層セキュリティ（TLS）の輸送時やSIPメッセージが断片化することなく、UDPパケットに収まるには大きすぎるを使用してセキュアSIP（SIPS）をサポートするために必要となる場合があります。連続した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と通信したいとき、SIPサーバを配置することもP2P SIPのために必要とされます。
4.6. : "Session Initiation Protocol (SIP)-Specific Event Notification"
4.6. ：「セッション開始プロトコル（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のために役立つことができ、そのいくつかの他の多くのSIPサービスのために使用されているものの最も顕著なイベント通知は、プレゼンスのために使用されているものです。
4.7. : "A Presence Event Package for the Session Initiation Protocol (SIP)"
4.7. ：「セッション開始プロトコル（SIP）のためのAのプレゼンスイベントパッケージ」
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の使用法を定義し、プレゼンス・イベントのためのSUBSCRIBE及びNOTIFYメソッドを利用します。 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で使用されます。
4.9. : "Session Initiation Protocol (SIP) Extension for Instant Messaging"
4.9. ：「インスタントメッセージングのためのセッション開始プロトコル（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におけるIMのためのSIP拡張3428 [9]だけIM会話状態は、エンドポイントまたはクライアント・インタフェースに存在するという仮定に基づいてIMのページャモデルのための（RFC 3428で定義）MESSAGEメソッドで構成されユーザーの心。
4.10. : "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)"
4.10. ：「セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化」
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）は、それぞれ、搬送SIPリクエストのIDヘッダ、および（2）識別情報ヘッダ、SIP要求及び署名されたID情報の部分上発行者の署名。署名はFROMヘッダと送信者のアイデンティティを含みます。関連識別情報ヘッダは、INVITEのようなSIPリクエストの送信者を識別する。署名の発行者は、同様にそれらの証明書を提示することができます。発行者は、ドメインの所有者であることが想定されます。強力な認証は、このようにSIPリクエストのために提供されます。 SIP応答の認証は、この文書で定義されていません。
4.11. : "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing"
4.11. ：「対称応答ルーティングのためのセッション開始プロトコル（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]応答が要求の発信元の送信元IPアドレスとポートに返送されるように、「RPORT」と呼ばれるSIPに拡張子を指定します。 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つの更新の例は、「INVITE要求をセッション開始プロトコルへの200の応答の取り扱い正しいトランザクション」[18]です。これは、RFC 3261に更新されます。 SIPのUAを不正な動作のための追加のセキュリティリスクは、転送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ベースのマルチメディア通信は、ウェブ上のさまざまな他のアプリケーションとリンクさせることができます。いくつかの非SIPアプリケーションまたは通信機能のいずれかが主な用途として知覚することができます。例では、ユーザーに高い関心のあるWebコンテンツとSIPベースのリアルタイム通信を混合されています。
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会議には、ユーザーの購入オプションに提示や情報を助けるために呼び出すことができます。この情報は、Web上のさまざまなソースからのリアルタイムデータを組み合わせてマッシュアップを利用することができます。
2. In a social network, multimedia conversations combined with Web mashups can be invoked, thus strengthening the bond between its members.
ソーシャルネットワーク2.、ウェブマッシュアップと組み合わせるマルチメディアの会話は、このように、そのメンバーの間の結合を強化し、呼び出すことができます。
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.
リアルタイムにWeb上でいくつかのイベントを見ながら3.会話を呼び出すことができます。会話がそのWebサイトを見ているユーザーのための時間を長くすることができますので、この場合の主な受益者は、Webサイトのかもしれません。
This shows the value of combining RIAs with SIP-based communications.
これは、SIPベースの通信を用いてRIAを組み合わせた値を示しています。
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.
[19]「呼制御およびSIPのためのマルチパーティの使用フレームワーク」O呼制御は、ピア・ツー・ピア機能の呼び出しモデルを使用し、参加エンドポイントに常駐テレフォニーアプリケーションの大規模な品揃えを提供します。ピア・ツー・ピア・デザインとその原則は、マルチパーティコール制御に基づいています。
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.
一の以上の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]総合STUN、TURN、およびICEの使用を要約して、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.
ICEの使用は、SIPを中心に開発されてきました。このようNICE（非SIPのための一般的な）とリアルタイムストリーミングプロトコル（RTSP）は、メディアをストリーミングするための「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トラバーサルのための一つのアプローチは、ホスト識別プロトコル（HIP）を展開し、HIPレベルで、一度だけNATトラバーサルを解決することです。 HIPは、この論文の範囲を超えて（例えば、エンドポイントにおけるIPv6への移行のためのサポート、モビリティ、およびマルチホーミングなど）は、多くの他の有用な特徴を有します。 [23]「ネットワークのトラバーサルのための基本的なHIP拡張機能は、翻訳者アドレス」NATトラバーサルのためのHIPの使用の広範な範囲を提供します。
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.
HIP対応エンドポイントを使用してIPv4とIPv6の両方のために、すべてのアプリケーションのために[24] NATトラバーサルのために必要な機能を提供することができます。それはSIP UAからNATトラバーサルの負担を奪うと、エンドポイントでのHIPプロトコルモジュールに移動するのでHIPは、このように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.
トランスポート・セキュリティおよびID：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のためのトランスポートセキュリティは、3261セキュアSIPリクエストURIで表記SIPSを持っており、TCP上のTLSを使用して、RFCで指定されています。 UDP経由のSIPは、このように確保することができないことに注意してください。トランスポートセキュリティの作品は唯一のホップでホップ。 SIPSを指定すると、すべての中間サーバーを信頼するように、ユーザーが必要とし、何のエンド・ツー・エンドのメディア暗号化を負いません。パスに仲介を不正な動作のための保険はありません。 SIPSは、そのためだけシングルホップシナリオで本当に十分です。
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].
RFC 4347で指定されたデータグラムトランスポート層セキュリティ（DTLS）O [25] UDP輸送を必要とする他のアプリケーションのための広い適用性を有します。 DTLSは、TLSで最大の共通性を持つように設計された、まだTCPトランスポートを必要とし、UDP上で動作しません。 DTLS-SRTPは、その指紋完全性保護SIPシグナリングチャネルを介して交換される自己署名証明書を使用して、エンドポイント間の暗号化通信をサポートすることができるフレームワーク[26]（リアルタイム転送プロトコルセキュア）。 [27]に記載されているようにSRTPマスタシークレットはDTLS交換を用いて導出されます。
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.
それは認証のための完全性保護SIPシグナリング経路を利用することができるもののO ZRTP [28]は、SIPシグナリングに依存せずに音声とマルチメディア通信用のSRTP用の鍵合意を提供します。 ZRTPは、証明書または公開鍵インフラストラクチャ（PKI）を使用する必要はありません。 ZRTPは、追加のSIP拡張子なしのベストエフォート型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.
著者は、このメモの最も最近の段階で有益なコメントのためのカレン・ジェニングス、ラルフDroms、およびエードリアンファレルに感謝したいと思います。
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を使用して緊急電話の使用を議論するためにそれらに挑戦するために、テレフォニーネットワークゲートウェイの役割を明確にするために、著者に挑戦してもキース糖剤のためにポールKyzivatによるものです。
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.
著者らはまた、SIPPING WGリストの詳細な議論のために智異Kuthan、エイドリアンGeorgescuなどに感謝したいと思います。その結果、我々はそれが何を目的としていないものを、単純なSIPが何ができるかの明確化、およびその間にいくつかのシナリオが追加されました。また、ネットワークベースのサービスとエンドポイントのアプリケーションとの違いを明確にする必要性に関するコメントの初期草案の詳細なレビューのためにとアルジュンRoychaudhuryにヴィルヘルムWimmreuterに感謝したいと思います。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[2]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 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]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivatを、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェント能力を示します"。
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[5]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[6]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[7] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[7]ローゼンバーグ、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]菅野、H.、藤本、S.、Klyne、G.、ベイトマン、A.、カー、W.、およびJ.ピーターソン、 "プレゼンス情報データフォーマット（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]キャンベル、B.、編。、ローゼンバーグ、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]ピーターソン、J.とC.ジェニングス、 "セッション開始プロトコル（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]ローゼンバーグ、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.
、RFC 5411 [12]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）ヒッチハイク・ガイド"、2009年2月。
[13] Ohlmeier, N., "VoIP RFC Watch", http://rfc3261.net/.
[13] Ohlmeier、N.、 "VoIPのRFCウォッチ"、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]ローゼン、B.とJ.ポーク、「緊急コールのサポートにおける通信サービスのための最も良い現在の練習」、進歩、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]ハーディ、T.、ニュートン、A.、Schulzrinneと、H.、およびH. Tschofenig、 "失われた：場所・ツー・サービス翻訳・プロトコル"、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]スパークス、R.、RFC 4320、2006年1月 "セッション開始プロトコル（SIP）非INVITEトランザクションと特定された問題への対処アクション"。
[18] Sparks, R. and T. Zourzouvillys, "Correct Transaction Handling for 200 Responses to Session Initiation Protocol INVITE Requests", Work in Progress, July 2009.
[18]スパークス、R.とT. Zourzouvillysは、進捗状況、2009年7月に、仕事を「セッション開始プロトコルへの200の応答の取り扱い正しいトランザクションは、INVITE要求を」。
[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]マーイ、R.、スパークス、R.、ローゼンバーグ、J.、ペトリ、D.、およびA.ジョンソン、「セッション開始プロトコル（SIP）のための呼制御とマルチパーティ利用フレームワーク」、仕事に進歩、2009年3月。
[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]ジョンストン、A.編、スパークス、R.、カニンガム、C.、ドノバン、S.、およびK.サマーズ、 "セッション開始プロトコルサービス例"、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]ボールトン、C.、ローゼンバーグ、J.、カマリロ、G.およびF. Audet、 "クライアント・サーバのSIP用NATトラバーサルのためのベストプラクティスの現在"、進歩、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]こむ、M.、ヘンダーソン、T.、Tschofenig、H.、メレン、J.およびA. Keraenenは、進歩、2009年6月に、仕事を "ネットワークのトラバーサルのための基本的なHIP拡張機能は、翻訳者アドレス"。
[24] Moskowitz, R., "HIP Experimentation using Teredo", July 2008, http://www.ietf.org/proceedings/08jul/slides/HIPRG-3.pdf.
[24]モスコウィッツ、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]レスコラ、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.レスコラ、 "DTLSを使用して、SRTPセキュリティコンテキストを確立するためのフレームワーク"、進歩、2009年3月での作業。
[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]マグリュー、D.およびE.レスコラ、「データグラムトランスポート層セキュリティ（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]ジマーマン、P.、ジョンストン、A.、およびJ.カラス、 "ZRTP：セキュア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]ピーターソン、J.、ジェニングス、C.及びR.スパークス、 "セッション開始プロトコル（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.
"ウェブ2.0を超え2 EXP（W）に向かって、" [30]ラマン、T.V.、ACMの通信、巻。 52、第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
ヘンリーSinnreichアドビシステムズ社601タウンゼント・ストリート、サンフランシスコ、CA 94103、USA
EMail: henrys@adobe.com
メールアドレス：henrys@adobe.com
Alan Johnston Avaya Saint Louis, MO, USA
ジョンストンアバイアセントルイス、MO、USA
EMail: alan@sipstation.com
メールアドレス：alan@sipstation.com
Eunsoo Shim Avaya Labs Research 233 Mount Airy Road Basking Ridge, NJ 07920 USA
Eunsooシムアバイア研究所研究233マウントエアリー道路バスキングリッジ、NJ 07920 USA
EMail: eunsooshim@gmail.com
メールアドレス：eunsooshim@gmail.com
Kundan Singh Columbia University Alumni 1214 Amsterdam Ave., MC0401 New York, NY, USA
パンシンコロンビア大学同窓会1214年アムステルダムアベニュー、MC0401ニューヨーク、NY、USA
EMail: kns10@cs.columbia.edu
メールアドレス：kns10@cs.columbia.edu