Network Working Group J. Rosenberg
Request for Comments: 4485 Cisco Systems
Category: Informational H. Schulzrinne
Columbia University
May 2006
Guidelines for Authors of Extensions to
the Session Initiation Protocol (SIP)
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) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions.
セッション開始プロトコル（SIP）は、インターネットを介して対話型通信セッションを確立するための柔軟かつシンプルなツールです。この柔軟性の一部は、それが拡張することができる容易さです。 SIPに効果的かつ相互運用可能な拡張を容易にするために、いくつかのガイドラインは、SIPの拡張機能を開発する際に続いする必要があります。この文書では、SIPの拡張機能の作者のため、このような一連のガイドラインを概説します。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Should I Define a SIP Extension? ................................3
3.1. SIP's Solution Space .......................................4
3.2. SIP Architectural Model ....................................5
4. Issues to Be Addressed ..........................................7
4.1. Backwards Compatibility ....................................7
4.2. Security ..................................................10
4.3. Terminology ...............................................10
4.4. Syntactic Issues ..........................................10
4.5. Semantics, Semantics, Semantics ...........................13
4.6. Examples Section ..........................................14
4.7. Overview Section ..........................................14
4.8. IANA Considerations Section ...............................14
4.9. Document-Naming Conventions ...............................16
4.10. Additional Considerations for New Methods ................16
4.11. Additional Considerations for New Header Fields
or Header Field ..........................................17
4.12. Additional Considerations for New Body Types .............18
5. Interactions with SIP Features .................................18
6. Security Considerations ........................................19
7. Acknowledgements ...............................................19
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................20
The Session Initiation Protocol (SIP) [2] is a flexible yet simple tool for establishing interactive communications sessions across the Internet. Part of this flexibility is the ease with which it can be extended (with new methods, new header fields, new body types, and new parameters), and there have been countless proposals that have been made to do just that. An IETF process has been put into place that defines how extensions are to be made to the SIP protocol [10]. That process is designed to ensure that extensions are made that are appropriate for SIP (as opposed to being done in some other protocol), that these extensions fit within the model and framework provided by SIP and are consistent with its operation, and that these extensions solve problems generically rather than for a specific use case. However, [10] does not provide the technical guidelines needed to assist that process. This specification helps to meet that need.
セッション開始プロトコル（SIP）は、[2]インターネット上の対話型通信セッションを確立するための柔軟かつシンプルなツールです。この柔軟性の一部は、それが（新しいメソッド、新しいヘッダフィールド、新しいボディタイプ、および新しいパラメータで）拡張することができる容易さで、ちょうどそれをするために行われてきた無数の提案がなされています。 IETFプロセスは、拡張子がSIPプロトコル[10]に行われるべき方法を定義する場所に置かれています。そのプロセスは、これらの拡張機能は、SIPによって提供されるモデルおよびフレームワーク内に適合し、その動作と一致していること、（いくつかの他のプロトコルで行われているとは対照的に）SIPのために適切であること拡張がなされていることを確認するように設計されており、これらの拡張ということです問題を解決するため、一般的ではなく、特定のユースケースのために。しかし、[10]は、そのプロセスを支援するために必要な技術的な指針を提供していません。この仕様は、そのニーズを満たすために役立ちます。
This specification first provides a set of guidelines to help decide whether a certain piece of functionality is appropriately done in SIP. Assuming the functionality is appropriate, it then points out issues that extensions should deal with from within their specification. Finally, it discusses common interactions with existing SIP features that often cause difficulties in extensions.
この仕様は、最初の機能の特定の部分が適切にSIPで行われているかどうかを判断するための一連のガイドラインを提供します。機能が適切であると仮定すると、それは、拡張子が彼らの仕様の中から対処すべき課題を指摘します。最後に、それは多くの場合、拡張の困難を引き起こす既存のSIP機能を備えた共通の相互作用について説明します。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" RFC 2119に記載されるように解釈されるべきである[1]と対応する実装の要求レベルを示します。
The first question to be addressed when defining a SIP extension is whether a SIP extension is the best solution to the problem. SIP has been proposed as a solution for numerous problems, including mobility, configuration and management, QoS control, call control, caller preferences, device control, third-party call control, and MPLS path setup, to name a few. Clearly, not every problem can be solved by a SIP extension. More importantly, some problems that could be solved by a SIP extension probably shouldn't.
SIPの拡張機能を定義する際に対処すべき最初の質問は、SIPの拡張機能が問題に最適なソリューションであるかどうかです。 SIPは、少数を示すために、制御、呼び出し側の好み、デバイス制御、サードパーティの呼制御、およびMPLSパスの設定を呼び出し、モビリティ、構成および管理、QoS制御など、多くの問題のための解決策として提案されています。明らかに、必ずしもすべての問題は、SIPの拡張機能によって解決することができます。さらに重要なのは、SIPの拡張機能によって解決することができ、いくつかの問題は、おそらくいけません。
To assist engineers in determining whether a SIP extension is an appropriate solution to their problem, we present two broad criteria. First, the problem SHOULD fit into the general purview of SIP's solution space. Secondly, the solution MUST conform to the general SIP architectural model.
SIPの拡張機能がその問題に適切なソリューションであるかどうかを決定する際にエンジニアを支援するために、我々は二つの大きな判断基準を提示します。まず、問題は、SIPの解空間の一般的な範囲に収まるべきです。第二に、解決策は、一般的なSIPアーキテクチャモデルに従わなければなりません。
Although the first criteria might seem obvious, we have observed that numerous extensions to SIP have been proposed because some function is needed in a device that also speaks SIP. The argument is generally given that "I'd rather implement one protocol than many". As an example, user agents, like all other IP hosts, need some way to obtain their IP address. This is generally done through DHCP [11]. SIP's multicast registration mechanisms might supply an alternate way to obtain an IP address. This would eliminate the need for DHCP in clients. However, we do not believe such extensions are appropriate. We believe that protocols should be defined to provide specific, narrow functions, rather than be defined for all protocols needed between a pair of devices. The former approach to protocol design yields modular protocols with broad application. It also facilitates extensibility and growth; single protocols can be removed and changed without affecting the entire system. We observe that this approach to protocol engineering mirrors object-oriented software engineering.
最初の基準は明らかに思えるかもしれないが、我々はいくつかの機能はまた、SIPを話すデバイスで必要とされているため、SIPに数多くの拡張が提案されていることを観察しました。引数は、一般的に「私はむしろ多くの数のプロトコルを実装したい」という与えられています。例として、ユーザエージェントは、他のすべてのIPホストのように、自分のIPアドレスを取得するためにいくつかの方法が必要です。これは、一般的にDHCP [11]を介して行われます。 SIPのマルチキャスト登録メカニズムは、IPアドレスを取得する別の方法を提供することがあります。これは、クライアントでDHCPの必要性を排除するであろう。しかし、我々はそのような拡張が適切であるとは思いません。私たちは、プロトコルは、特定の狭い機能を提供するために定義されるべきであると信じているのではなく、デバイスのペア間で必要なすべてのプロトコルのために定義すること。プロトコルの設計に前者のアプローチは、幅広いアプリケーションにモジュラープロトコルを生成します。また、拡張性と成長を促進します。単一のプロトコルは、システム全体に影響を与えることなく、削除、変更することができます。私たちは、プロトコル工学へのこのアプローチは、オブジェクト指向のソフトウェア・エンジニアリングを反映することを確認します。
Our second criteria, that the extension must conform to the general SIP architectural model, ensures that the protocol remains manageable and broadly applicable.
私たちの第二の基準は、拡張子は一般的なSIPアーキテクチャモデルに適合しなければならないことを、プロトコルが管理可能と広く適用ままであることを保証します。
In order to evaluate the first criteria, it is necessary to define exactly what SIP's solution space is, and what it is not.
最初の基準を評価するためには、SIPの解空間が正確に定義する必要があり、それは何ではありません。
SIP is a protocol for initiating, modifying, and terminating interactive sessions. This process involves the discovery of users, (or, more generally, entities that can be communicated with, including services, such as voicemail or translation devices) wherever they may be located, so that a description of the session can be delivered to the user. It is assumed that these users or communications entities are mobile, and that their point of attachment to the network changes over time. The primary purpose of SIP is a rendezvous function, to allow a request initiator to deliver a message to a recipient wherever they may be. Such a rendezvous is needed to establish a session, but it can be used for other purposes related to communications, such as querying for capabilities or delivery of an instant message.
SIPは、開始、変更、および対話型セッションを終了するためのプロトコルです。セッションの記述がユーザに配信することができるように、彼らは、配置することができるところはどこでも、このプロセスは、（ボイスメールまたは翻訳デバイスとして、あるいは、より一般的には、サービスを含めて通信することができるエンティティ、、）ユーザーの発見を含みます。これらのユーザーまたは通信エンティティは、モバイル、および時間をかけてネットワークの変更への結合彼らのポイントということであると仮定する。 SIPの主な目的は、要求イニシエータは、彼らがどこであってもよい受信者にメッセージを配信できるようにするために、ランデブー関数です。そのようなランデブーは、セッションを確立するために必要とされるが、それはそのような機能やインスタントメッセージの送達のための照会などの通信に関連する他の目的に使用することができます。
Much of SIP focuses on this discovery and rendezvous component. Its ability to fork, its registration capabilities, and its routing capabilities are all present for the singular purpose of finding the desired user wherever they may be. As such, features and capabilities such as personal mobility, automatic call distribution, and follow-me are well within the SIP solution space.
SIPの多くは、この発見とランデブーコンポーネントに焦点を当てています。フォークにその能力、その登録機能、ルーティング機能はすべて、彼らがどこであってもよい所望のユーザを見つける特異目的のために存在しています。パーソナルモビリティ、自動呼分配など、機能や性能など、およびフォローミーSIPソリューション空間の範囲内です。
Session initiation also depends on the ability of the called party to have enough information about the session itself to make a decision on whether to join. That information includes data about the caller, the purpose for the invitation, and parameters of the session itself. For this reason, SIP includes this kind of information.
セッション開始はまた、参加するかどうかの決定を行うためにセッション自体についての十分な情報を持っている着信側の能力に依存します。その情報は、発信者、招待のための目的、及びセッション自体のパラメータに関するデータを含んでいます。このため、SIPは、この種の情報を含んでいます。
Part of the process of session initiation is the communication of progress and the final results of establishment of the session. SIP provides this information as well.
セッション開始プロセスの一部は、進行の通信およびセッションの確立の最終結果です。 SIPは、同様にこの情報を提供します。
SIP itself is independent of the session, and the session description is delivered as an opaque body within SIP messages. Keeping SIP independent of the sessions it initiates and terminates is fundamental. As such, there are many functions that SIP explicitly does not provide. It is not a session management protocol or a conference control protocol. The particulars of the communications within the session are outside of SIP. This includes features such as media transport, voting and polling, virtual microphone passing, chairman election, floor control, and feedback on session quality.
SIP自体は、セッションの独立しており、セッション記述は、SIPメッセージ内の不透明体として提供されます。それは開始と終了セッションのSIPから独立を保つことは基本です。そのため、SIPが明示的に提供していない多くの機能があります。これは、セッション管理プロトコルや会議制御プロトコルではありません。セッション内の通信の詳細は、SIPの外にあります。これは、メディア転送、投票及び投票、仮想マイクの受け渡し、会長選挙、フロア制御、およびセッションの品質に関するフィードバックなどの機能が含まれています。
SIP is not a resource reservation protocol for sessions. This is fundamentally because (1) SIP is independent of the underlying session it establishes, and (2) the path of SIP messages is completely independent from the path that session packets may take. The path independence refers to paths within a provider's network and the set of providers itself. For example, it is perfectly reasonable for a SIP message to traverse a completely different set of autonomous systems than the audio in a session SIP establishes.
SIPは、セッションのためのリソース予約プロトコルではありません。 （1）SIPは、それが確立下地セッションとは無関係である、及び（2）SIPメッセージの経路がセッションパケットがとり得る経路から完全に独立しているので、これは基本的です。パスの独立は、プロバイダのネットワーク内の経路及びプロバイダ自体のセットを指します。例えば、SIPが確立、セッションのオーディオより自律システムの完全に異なるセットを横断するSIPメッセージの完全に合理的です。
SIP is not a general purpose transfer protocol. It is not meant to send large amounts of data unrelated to SIP's operation. It is not meant as a replacement for HTTP. This is not to say that carrying payloads in SIP messages is never a good thing; in many cases, the data is very much related to SIP's operation. In those cases, congestion-controlled transports end-to-end are critical.
SIPは、汎用転送プロトコルではありません。 SIPの操作に関係のない大量のデータを送信するものではありません。これは、HTTPの代替として意図されていません。これは、SIPメッセージにペイロードを運ぶことは良いことになることはありませんと言っているわけではありません。多くの場合、データは非常に多くのSIPの操作に関連しています。これらの例では、輻輳制御のトランスポートは、エンドツーエンド重大です。
SIP is not meant to be a general Remote Procedure Call (RPC) mechanism. None of its user discovery and registration capabilities are needed for RPC, and neither are most of its proxy functions.
SIPは、一般的なリモートプロシージャコール（RPC）のメカニズムであることを意味しません。その利用者の発見および登録機能はどれも、RPCのために必要ありませんし、どちらもそのプロキシ機能のほとんどをされています。
SIP is not meant to be used as a strict Public Switched Telephone Network (PSTN) signaling replacement. It is not a superset of the Integrated Services Digital Network (ISDN) User Part (ISUP). Although it can support gatewaying of PSTN signaling and can provide many features present in the PSTN, the mere existence of a feature or capability in the PSTN is not a justification for its inclusion in SIP. Extensions needed to support telephony MUST meet the other criteria described here.
SIPは、厳密な公衆交換シグナリング交換電話網（PSTN）として使用されるものではありません。これは、総合デジタル通信網（ISDN）ユーザ部（ISUP）のスーパーセットではありません。それはPSTNシグナリングのゲートウェイをサポートすることができ、PSTNに存在する多くの機能を提供することができるが、PSTN内の特徴または機能の単なる存在は、SIPでの包含のために正当化されません。テレフォニーをサポートするために必要な拡張機能は、ここで説明する他の基準を満たさなければなりません。
SIP is a poor control protocol. It is not meant to be used for one entity to tell another to pick up or answer a phone, to send audio using a particular codec, or to provide a new value for a configuration parameter. Control protocols have different trust relationships from that assumed in SIP and are more centralized in architecture than SIP is, as SIP is a very distributed protocol.
SIPは乏しい制御プロトコルです。特定のコーデックを使用してオーディオを送信するために、携帯電話を拾うか、答えるために別のものを伝えるために、または構成パラメータの新しい値を提供するために、一方のエンティティのために使用されるものではありません。制御プロトコルはSIPで想定とは異なる信頼関係を持っており、SIPは非常に分散プロトコルであるように、SIPはよりアーキテクチャにおいてより集中しています。
There are many network layer services needed to make SIP function. These include quality of service, mobility, and security, among others. Rather than build these capabilities into SIP itself, they SHOULD be developed outside of SIP and then used by it. Specifically, any protocol mechanisms that are needed by SIP, but that are also needed by many other application layer protocols SHOULD NOT be addressed within SIP.
SIP機能を作るために必要な多くのネットワークレイヤサービスがあります。これらは、とりわけ、サービスの品質、モビリティ、およびセキュリティが含まれます。 SIP自体にこれらの機能を構築するのではなく、それらはSIPの外で開発し、それによって使用されるべきです。 SIPによって必要とされる具体的には、任意のプロトコルメカニズムが、SIP内でアドレス指定されるべきではないことも、他の多くのアプリケーション層プロトコルによって必要とされます。
We describe here some of the primary architectural assumptions that underlie SIP. Extensions that violate these assumptions should be examined more carefully to determine their appropriateness for SIP.
ここでは、SIPの基礎となる主要な建築仮定のいくつかを説明します。これらの仮定に違反する拡張機能は、SIPのための彼らの妥当性を判断するために、より慎重に検討する必要があります。
Session independence: SIP is independent of the session it establishes. This includes the type of session, be it audio, video, game, chat session, or virtual reality. SIP operation SHOULD NOT depend on some characteristic of the session. SIP is not specific to voice only. Any extensions to SIP MUST consider the application of SIP to a variety of different session types.
セッションの独立性：SIPは、それが確立したセッションとは無関係です。これは、セッションのタイプを含み、それは、オーディオ、ビデオ、ゲームも、セッション、または仮想現実をチャット。 SIP操作は、セッションのいくつかの特性に依存するべきではありません。 SIPは音声だけに固有ではありません。 SIPへの任意の拡張子が異なるセッションタイプの様々なSIPの適用を検討する必要があります。
SIP and Session path independence: We have already touched on this once, but it is worth noting again. The set of routers, networks, and/or autonomous systems traversed by SIP messages are unrelated to the set of routers, networks, and/or autonomous systems traversed by session packets. They may be the same in some cases, but it is fundamental to SIP's architecture that they need not be the same. Standards-track extensions MUST NOT be defined that work only when the signaling and session paths are coupled. Non-standard P-header extensions [10] are required for any extension that only works in such a case.
SIPおよびセッションパスの独立性：我々はすでに一度これに触れてきたが、それが再び注目されます。 SIPメッセージによって横断ルータ、ネットワーク、および/または自律システムのセットは、ルータ、ネットワーク、および/またはセッションパケットが横断する自律システムのセットとは無関係です。彼らは、いくつかのケースでは同じかもしれないが、それは彼らが同じである必要はないSIPのアーキテクチャの基本です。標準トラックの拡張機能は、シグナリングおよびセッションパスが結合されているだけでその作業を定義してはなりません。非標準P-ヘッダ拡張子[10]のみこのような場合に動作する任意の拡張のために必要とされます。
Multi-provider and multi-hop: SIP assumes that its messages will traverse the Internet. That is, SIP works through multiple networks administered by different providers. It is also assumed that SIP messages traverse many hops (where each hop is a proxy). Extensions MUST NOT work only under the assumption of a single hop or specialized network topology. They SHOULD avoid the assumption of a single SIP provider (but see the use of P-Headers, per RFC 3427 [10]).
マルチプロバイダとマルチホップ：SIPは、そのメッセージがインターネットを通過することを前提としています。つまり、SIPは、異なるプロバイダによって投与される複数のネットワークを介して動作します。また、SIPメッセージは、（各ホッププロキシである）は、多くのホップを横断することが想定されます。拡張機能は、シングルホップや特殊なネットワークトポロジの仮定の下でのみ動作してはなりません。彼らは、（[10]が、P-ヘッダの使用を参照して、RFC 3427ごとに）単一のSIPプロバイダの仮定を避けるべきです。
Transactional: SIP is a request/response protocol, possibly enhanced with intermediate responses. Many of the rules of operation in SIP are based on general processing of requests and responses. This includes the reliability mechanisms, routing mechanisms, and state maintenance rules. Extensions SHOULD NOT add messages that are not within the request-response model.
トランザクション：SIPはおそらく中間応答で強化要求/応答プロトコルです。 SIPでの操作の規則の多くは、要求と応答の一般的な処理に基づいています。これは、信頼性メカニズム、ルーティングメカニズム、及び状態維持規則を含みます。拡張機能は、要求 - 応答モデル内にないメッセージを追加しないでください。
Proxies can ignore bodies: In order for proxies to scale well, they must be able to operate with minimal message processing. SIP has been engineered so that proxies can always ignore bodies. Extensions SHOULD NOT require proxies to examine bodies.
プロキシは、ボディを無視することができます。プロキシがうまくスケールするためには、彼らは、最小限のメッセージ処理で動作することができなければなりません。プロキシが常に体を無視できるように、SIPは設計されています。拡張機能は、遺体を調べるためにプロキシを必要とすべきではありません。
Proxies don't need to understand the method: Processing of requests in proxies does not depend on the method, except for the well-known methods INVITE, ACK, and CANCEL. This allows for extensibility. Extensions MUST NOT define new methods that must be understood by proxies.
プロキシは、この方法を理解する必要はありません：プロキシでリクエストの処理は、方法に依存し、よく知られた方法を除き、INVITE、ACK、およびキャンセルされません。これは、拡張することができます。拡張機能は、プロキシによって理解されなければならない新しいメソッドを定義してはなりません。
INVITE messages carry full state: An initial INVITE message for a session is nearly identical (the exception is the tag) to a re-INVITE message to modify some characteristic of the session. This full state property is fundamental to SIP and is critical for robustness of SIP systems. Extensions SHOULD NOT modify INVITE processing such that data spanning multiple INVITEs must be collected in order to perform some feature.
メッセージがフル状態を運ぶINVITE：最初のセッションのためのINVITEメッセージは、セッションのいくつかの特性を修正するために再INVITEメッセージに（例外はタグである）は、ほぼ同じです。この完全な状態のプロパティは、SIPの基本であるとSIPシステムの堅牢性のために重要です。拡張機能は、複数のINVITEにまたがるデータは、いくつかの機能を実行するために収集されなければならないこと等の処理INVITE変更すべきではありません。
Generality over efficiency: Wherever possible, SIP has favored general-purpose components rather than narrow ones. If some capability is added to support one service but a slightly broader capability can support a larger variety of services (at the cost of complexity or message sizes), the broader capability SHOULD be preferred.
効率上一般には：可能な限り、SIPは、狭いものではなく、汎用部品を支持しています。いくつかの機能は、1つのサービスをサポートするために追加されるが、わずかに広い能力が（複雑またはメッセージのサイズを犠牲にして）サービスのより大きな多様性をサポートすることができる場合は、より広範な機能が好まれるべきです。
The Request URI is the primary key for forwarding: Forwarding logic at SIP servers depends primarily on the request URI (this is different from request routing in SIP, which uses the Route header fields to pass a request through intermediate proxies). It is fundamental to the operation of SIP that the request URI indicate a resource that, under normal operations, resolves to the desired recipient. Extensions SHOULD NOT modify the semantics of the request URI.
リクエストURIは、転送のための基本キーである：SIPサーバに転送ロジックは、リクエストURI（これは中間プロキシを介して要求を渡すためにRouteヘッダフィールドを使用してSIPのルーティング要求とは異なる）に主に依存します。要求URIは、通常の動作の下、所望の受信者に解決、リソースを示すことSIPの動作の基本です。拡張機能は、リクエストURIのセマンティクスを変更しないでください。
Heterogeneity is the norm: SIP supports heterogeneous devices. It has built-in mechanisms for determining the set of overlapping protocol functionalities. Extensions SHOULD NOT be defined that only function if all devices support the extension.
不均一性は当たり前です：SIPは、異種デバイスをサポートしています。これは、組み込まれている機構重複プロトコルの機能のセットを決定します。拡張機能は、すべてのデバイスが拡張をサポートしている場合にのみ機能することを定義しないでください。
Given an extension has met the litmus tests in the previous section, there are several issues that all extensions should take into consideration.
拡張子は、前のセクションでリトマステストを満たしている考えると、すべての拡張機能は、考慮すべきいくつかの問題があります。
One of the most important issues to consider is whether the new extension is backward compatible with baseline SIP. This is tightly coupled with how the Require, Proxy-Require, and Supported header fields are used.
考慮すべき最も重要な問題の一つは、新しい拡張は、ベースラインSIPとの下位互換性があるかどうかです。これはしっかりプロキシは、要求、要求、およびサポートされているヘッダーフィールドが使用されている方法で結合されています。
If an extension consists of new header fields or header field parameters inserted by a user agent in a request with an existing method, and the request cannot be processed reasonably by a proxy and/or user agent without understanding the header fields or parameters, the extension MUST mandate the usage of the Require and/or Proxy-Require header fields in the request. These extensions are not backwards compatible with SIP. The result of mandating usage of these header fields means that requests cannot be serviced unless the entities being communicated with also understand the extension. If some entity does not understand the extension, the request will be rejected. The UAC can then handle this in one of two ways. In the first, the request simply fails, and the service cannot be provided. This is basically an interoperability failure. In the second case, the UAC retries the request without the extension. This will preserve interoperability, at the cost of a "dual stack" implementation in a UAC (processing rules for operation with and without the extension). As the number of extensions increases, this leads to an exponential explosion in the sets of processing rules a UAC may need to implement. The result is excessive complexity.
拡張は、既存の方法で要求にユーザエージェントによって挿入された新たなヘッダフィールドまたはヘッダフィールドパラメータで構成され、リクエストヘッダフィールドまたはパラメータ、拡張を理解することなく、プロキシおよび/またはユーザエージェントによって合理的に処理できない場合要求で要求および/またはプロキシ要求ヘッダフィールドの使用を強制しなければなりません。これらの拡張機能は、SIPとの下位互換性がありません。これらのヘッダフィールドの使用を義務化した結果は、エンティティはまた、拡張を理解するに連通している場合を除き要求がサービスされないことを意味します。いくつかの実体が拡張を理解していない場合、要求は拒否されます。 UACは、次のいずれかの方法でこれを処理することができます。最初に、要求は単に失敗し、サービスを提供することができません。これは、基本的には相互運用性の障害です。後者の場合、UACは、拡張せずに要求を再試行します。これは、（拡張子を持つとせずに操作するためのルールを処理する）UACの「デュアルスタック」実装のコストで、相互運用性を保持します。拡張機能の数が増加するように、これは、処理のセットの指数関数的爆発につながるUACを実装する必要があるかもしれないルール。その結果、過度の複雑さです。
Because of the possibility of interoperability and complexity problems that result from the usage of Require and Proxy-Require, we believe the following guidelines are appropriate:
そのため必要とプロキシ要求の使用に起因する相互運用性と複雑さの問題の可能性、私たちは、次のガイドラインが適切であると考えています。
o The usage of these header fields in requests for basic SIP services (in particular, session initiation and termination) is NOT RECOMMENDED. The less frequently a particular extension is needed in a request, the more reasonable it is to use these header fields.
oを基本的なSIPサービス（特に、セッション開始および終結）の要求でこれらのヘッダフィールドの使用は推奨されません。それほど頻繁に特定の拡張を要求に必要とされる、より合理的なことは、これらのヘッダフィールドを使用することです。
o The Proxy-Require header field SHOULD be avoided at all costs. The failure likelihood in an individual proxy stays constant, but the path failure grows exponentially with the number of hops. On the other hand, the Require header field only mandates that a single entity, the UAS, support the extension. Usage of Proxy-Require is thus considered exponentially worse than usage of the Require header field.
Oプロキシ-Requireヘッダーフィールドは、すべてのコストで回避する必要があります。個々のプロキシでの失敗確率は一定ではなく、パスの障害は、ホップ数に応じて指数関数的に増大します。一方、要求ヘッダーフィールドは、単一のエンティティ、UASは、拡張をサポートすることを義務付け。プロキシ要求の使用は、このように必要とヘッダーフィールドの使用よりも指数関数的に悪いと考えられています。
o If either Require or Proxy-Require are used by an extension, the extension SHOULD discuss how to fall back to baseline SIP operation if the request is rejected with a 420 response.
どちらかが必要とするか、または拡張によって使用されるプロキシは、必要な場合はO、拡張要求は420応答で拒否された場合、ベースラインSIP動作にフォールバックする方法について説明すべきです。
Extensions that define new methods do not need to use the Require header field. SIP defines mechanisms that allow a UAC to know whether a new method is understood by a UAS. This includes both the OPTIONS request and the 405 (Method Not Allowed) response with the Allow header field. It is fundamental to SIP that proxies need not understand the semantics of a new method in order to process it. If an extension defines a new method that must be understood by proxies in order to be processed, a Proxy-Require header field is needed. As discussed above, these kinds of extensions are frowned upon.
新しいメソッドを定義する拡張機能は、Requireヘッダーフィールドを使用する必要はありません。 SIP UACは、新しい方法はUASによって理解されているかどうかを知ることができるようにメカニズムを定義します。これは、OPTIONS要求及び許可ヘッダフィールドと405（方法不可）応答の両方を含みます。プロキシがそれを処理するために新しい方法の意味を理解する必要がないことをSIPに基本です。拡張機能が処理されるためにプロキシによって理解されなければならない新しいメソッドを定義する場合、プロキシ要求ヘッダーフィールドが必要です。上述したように、拡張のこれらの種類は、眉をひそめるされています。
In order to achieve backwards compatibility for extensions that define new methods, the Allow header field is used. There are two types of new methods - those that are used for established dialogs (initiated by INVITE, for example), and those that are sent as the initial request to a UA. Since INVITE and its response both SHOULD contain an Allow header field, a UA can readily determine whether the new method can be supported within the dialog. For example, once an INVITE dialog is established, a user agent could determine whether the REFER method [12] is supported if it is present in an Allow header field. If it wasn't, the "transfer" button on the UI could be "greyed out" once the call is established.
新しいメソッドを定義拡張の下位互換性を実現するために、許可ヘッダーフィールドが使用されます。 （例えば、INVITEによって開始される）確立ダイアログのために使用されるもの、およびUAに最初の要求として送信されるもの - 2つの新しいメソッドのタイプがあります。 INVITEとその応答の両方を許可ヘッダーフィールドを含む必要があるため、UAは、容易に新しい方法がダイアログ内でサポートすることができるかどうかを決定することができます。 INVITEダイアログが確立されると、例えば、ユーザーエージェントは、許可ヘッダーフィールドに存在する場合REFERメソッド[12]サポートされているかどうかを決定することができます。それがなかった場合、コールが確立されると、UI上の「転送」ボタンは、「グレー表示」することができます。
Another type of extension is that which requires a proxy to insert header fields or header field parameters into a request as it traverses the network, or for the UAS to insert header fields or header field parameters into a response. For some extensions, if the UAC or UAS does not understand these header fields, the message can still be processed correctly. These extensions are completely backwards compatible.
拡張の他のタイプは、応答にヘッダーフィールドまたはヘッダフィールドパラメータを挿入することは、ネットワークを横断するように要求にヘッダーフィールドまたはヘッダフィールドパラメータを挿入するためにプロキシが必要、またはUASのためのものです。 UACまたはUASはこれらのヘッダーフィールドを理解していない場合はいくつかの拡張機能については、メッセージはまだ正しく処理することができます。これらの拡張機能は完全に後方互換性があります。
Most other extensions of this type require that the server only insert the header field or parameter if it is sure the client understands it. In this case, these extensions will need to make use of the Supported request header field mechanism. This mechanism allows a server to determine if the client can understand some extension, so that it can apply the extension to the response. By their nature, these extensions may not always be able to be applied to every response.
このタイプの他のほとんどの拡張機能は、クライアントがそれを理解して確実である場合は、サーバーが唯一のヘッダフィールドまたはパラメータを挿入する必要があります。この場合、これらの拡張機能はサポートされているリクエストヘッダフィールドメカニズムを利用する必要があります。このメカニズムは、それが応答に拡張子を適用することができるように、クライアントは、いくつかの拡張機能を理解することができた場合、サーバが決定することができます。その性質上、これらの拡張機能は、常にすべてのレスポンスに適用することができない場合があります。
If an extension requires a proxy to insert a header field or parameter into a request and this header field or parameter needs to be understood by both UAC and UAS to be executed correctly, a combination of the Require and the Supported mechanism will need to be used. The proxy can insert a Require header field into the request if the Supported header field is present. An example of such an extension is the SIP Session Timer [13].
拡張は、リクエストにヘッダーフィールドまたはパラメータを挿入するためにプロキシを必要とし、このヘッダーフィールドまたはパラメータが正しく実行されるUACとUASの両方によって理解される必要がある、必須の組み合わせとサポート機構が使用される必要がある場合。 Supportedヘッダーフィールドが存在する場合、プロキシは、リクエストにRequireヘッダーフィールドを挿入することができます。そのような拡張の一例は、SIPセッションタイマー[13]です。
Yet another type of extension is that which defines new body types to be carried in SIP messages. According to the SIP specification, bodies must be understood by user agents in order to process a request. As such, the interoperability issues are similar to new methods. However, the Content-Disposition header field has been defined to allow a client or server to indicate that the message body is optional [2]. Extensions that define or require new body types SHOULD make them optional for the user agent to process.
まだ拡張の別のタイプは、SIPメッセージで運ばれるべき新しいボディタイプを定義するものです。 SIPの仕様によれば、本体は、要求を処理するためにユーザエージェントによって理解されなければなりません。そのため、相互運用性の問題は、新しいメソッドに似ています。しかし、コンテンツの廃棄ヘッダーフィールドは、メッセージ本体がオプションであることを示すために、クライアントまたはサーバを許可するように定義されている[2]。定義または新しいボディタイプが必要な拡張機能は、ユーザエージェントが処理するためにそれらをオプションにすべきです。
When a body must be understood to properly process a request or response, it is preferred that the sending entity know ahead of time whether the new body is understood by the recipient. For requests that establish a dialog, inclusion of Accept in the request and its success responses is RECOMMENDED. This will allow both parties to determine what body types are supported by their peers. Subsequent messaging between the peers would then only include body types that were indicated as being understood.
体が正常に要求または応答を処理するために理解しなければならない場合は、送信エンティティは、新しいボディが受信者に理解されているかどうかを前もって知っていることが好ましいです。ダイアログを確立する要求の場合、要求とその成功応答の受け入れを含めることをお勧めします。これは、両方の当事者がボディタイプは仲間によってサポートされているかを判断することができます。ピア間の後続のメッセージは、その後のみ理解されるものとして示されたボディタイプを含むであろう。
Security is an important component of any protocol. Designers of SIP extensions need to carefully consider if additional security requirements are required over those described in RFC 3261. Frequently, authorization requirements and requirements for end-to-end integrity are the most overlooked.
セキュリティは、任意のプロトコルの重要な構成要素です。 SIP拡張の設計者は、追加のセキュリティ要件は、多くの場合、許可要件とエンドツーエンドの完全性に対する要件が最も見過ごされ、RFC 3261に記載されたものの上に必要とされる場合には慎重に検討する必要があります。
SIP extensions MUST consider how (or if) they affect usage of the general SIP security mechanisms. Most extensions should not require any new security capabilities beyond general-purpose SIP. If they do, it is likely that the security mechanism has more general-purpose application and should be considered an extension in its own right.
SIPの拡張は、彼らは一般的なSIPのセキュリティメカニズムの使用をどのように影響するか（または場合）を考慮しなければなりません。ほとんどの拡張機能は、汎用SIPを越えた新たなセキュリティ機能を必要とすべきではありません。彼らが行う場合は、セキュリティ・メカニズムは、より汎用的なアプリケーションを持っており、それ自体で拡張を検討すべきであると思われます。
Overall system security requires that both the SIP signaling and the media sessions it established be secured. The media sessions normally use their own security techniques, which are quite distinct from those used by SIP itself. Extensions should take care not to conflate the two. However, specifications that define extensions that impact the media sessions in any way SHOULD consider the interactions between SIP and session security mechanisms.
システム全体のセキュリティは、それが確立されたSIPシグナリングおよびメディア・セッションの両方を確保する必要があります。メディアセッションは、通常、SIP自体が使用するものとは全く異なる独自のセキュリティ技術を使用しています。拡張機能には、両者を融合するないように注意する必要があります。しかし、どのような方法でメディアセッションに影響を与えるの拡張機能を定義する仕様は、SIPおよびセッションセキュリティメカニズム間の相互作用を考慮すべきです。
RFC 3261 has an extensive terminology section that defines terms such as caller, callee, user agent, and header field. All SIP extensions MUST conform to this terminology. They MUST NOT define new terms that describe concepts already defined by a term in another SIP specification. If new terminology is needed, it SHOULD appear in a separate section towards the beginning of the document.
RFC 3261は、発呼者、被呼者、ユーザーエージェント、およびヘッダ・フィールドのような用語を定義する広範な用語部を有しています。すべてのSIPの拡張は、この用語に従わなければなりません。彼らはすでに別のSIP明細書中で定義された概念を説明し、新たな用語を定義してはなりません。新しい用語が必要な場合は、ドキュメントの先頭に向けた別のセクションに表示されます。
Careful attention must be paid to the actual usage of terminology. Many documents misuse the terms header, header field, and header field values, for example. Document authors SHOULD do a careful review of their documents for proper usage of these terms.
細心の注意を払うことが、専門用語の実際の使用に注意を払わなければなりません。多くの文書は、例えば、用語ヘッダ、ヘッダフィールド、ヘッダフィールド値を誤用します。文書作成者は、これらの用語の適切な使用のために彼らの文書を慎重に検討を行う必要があります。
Extensions that define new methods SHOULD use all capitals for the method name. Method names SHOULD be shorter than 10 characters and SHOULD attempt to convey the general meaning of the request. Method names are case sensitive, and therefore, strictly speaking, they don't have to be capitalized. However, using capitalized method names keeps with a long-standing convention in SIP and many similar protocols, such as HTTP [15] and RTSP [16].
新しいメソッドを定義する拡張機能は、メソッド名にすべて大文字を使用すべきです。メソッド名は10文字未満である必要があり、要求の一般的な意味を伝えるしようとすべきです。メソッド名は大文字と小文字が区別され、したがって、厳密に言えば、彼らは大文字にする必要はありません。しかし、大文字のメソッド名を使用してSIPにおける長年の慣習や、HTTP [15]及びRTSP [16]などの多くの同様のプロトコルを用いて維持します。
Extensions that define new header fields that are anticipated to be heavily used MAY define a compact form if those header fields are more than six characters. "Heavily used" means that the percentage of all emitted messages that contain that header field is over thirty percent. Usage of compact forms in these cases is only a MAY because there are better approaches for reducing message overhead [20]. Compact header fields MUST be a single character. When all 26 characters are exhausted, new compact forms will no longer be defined. Header field names are defined by the "token" production in RFC 3261, Section 25.1, and thus include the upper and lowercase letters, the digits 0 through 9, the HYPHEN-MINUS (-), FULL STOP (.), EXCLAMATION MARK (!), PERCENT SIGN (%), ASTERISK (*), LOW LINE (_), PLUS SIGN (+), GRAVE ACCENT (`), APOSTROPHE ('), and TILDE (~). They SHOULD be descriptive but reasonably brief. Although header field names are case insensitive, a single common capitalization SHOULD be used throughout the document. It is RECOMMENDED that each English word present in the header field name have its first letter capitalized. For example, "ThisIsANewHeader".
これらのヘッダフィールドが6文字以上である場合に頻繁に使用されると予想される新しいヘッダフィールドを定義する拡張機能は、コンパクトな形状を定義することもできます。 「使用頻度の高い」というヘッダ・フィールドを含むすべて放出されたメッセージの割合が30％以上であることを意味します。メッセージのオーバーヘッドを低減するためのより良いアプローチ[20]があるので、これらの場合にコンパクトな形態の使用は、MAYあります。コンパクトヘッダフィールドは、単一の文字でなければなりません。すべての26の文字が排出される場合は、新しいコンパクトなフォームはもはや定義されません。ヘッダフィールド名はRFC 3261、セクション25.1に「トークン」の生産によって定義され、したがって、大文字と小文字、0〜9の数字が含まれるハイフンマイナス（ - ）、ピリオド、感嘆符（（。） ！）、パーセント記号（％）、アスタリスク（*）、LOW LINE（_）、PLUS SIGN（+）、GRAVEアクセント（ `）、アポストロフィ（ '）、およびチルダ（〜）。彼らは、記述が、合理的に簡単であるべきです。ヘッダフィールド名は大文字と小文字を区別しているが、単一の共通総額は文書全体を通して使用されるべきです。ヘッダーフィールド名に存在する各英単語は、その最初の文字は大文字にすることをお勧めします。例えば、 "ThisIsANewHeader"。
As an example, the following are poor choices for header field names:
一例として、次のヘッダフィールド名の貧しい選択肢は次のとおりです。
ThisIsMyNewHeaderThatDoesntDoVeryMuchButItHasANiceName --.!A Function
ThisIsMyNewHeaderThatDoesntDoVeryMuchButItHasANiceName - 。！機能
Case sensitivity of parameters and values is a constant source of confusion, a difficulty that plagued RFC 2543 [17]. This has been simplified through the usage of the BNF constructs of RFC 4234 [5], which have clear rules of case sensitivity and insensitivity. Therefore, the BNF for an extension completely defines the matching rules.
パラメータと値の大文字小文字の区別は、混乱の一定の源、RFC 2543 [17]悩まさ困難です。これは、大文字と小文字の区別および非感受性の明確なルールを持っているRFC 4234 [5]のBNF構築物の使用を介して簡略化されています。したがって、拡張のためのBNFは、完全に一致するルールを定義します。
Extensions MUST be consistent with the SIP conventions for case sensitivity. Methods MUST be case sensitive. Header field names MUST be case insensitive. Header field parameter names MUST be case insensitive. Header field values and parameter values are sometimes case sensitive, and sometimes case insensitive. However, generally, they SHOULD be case insensitive. Defining a case-sensitive component requires explicitly listing each character through its ASCII code.
拡張機能は、大文字と小文字の区別のためのSIPの規則と一致していなければなりません。メソッドは大文字と小文字を区別しなければなりません。ヘッダーフィールド名は大文字と小文字を区別しなければなりません。ヘッダーフィールドパラメータ名は大文字小文字を区別してはなりません。ヘッダーフィールド値とパラメータ値は時々大文字と小文字が区別され、時には大文字と小文字を区別しません。しかし、一般的に、彼らは大文字と小文字を区別すべきである（SHOULD）。大文字と小文字を区別コンポーネントを定義すると、明示的にASCIIコードを介して文字をリストが必要です。
Extensions that contain freeform text MUST allow that text to be UTF-8, as per the IETF policies on character set usage [3]. This ensures that SIP remains an internationalized standard. As a general guideline, freeform text is never needed by programs to perform protocol processing. It is usually entered by and displayed to the user. If an extension uses a parameter that can contain UTF-8- encoded characters, and that extension requires a comparison to be made of this parameter to other parameters, the comparison MUST be case sensitive. Case-insensitive comparison rules for UTF-8 text are, at this time, impossible and MUST be avoided.
自由形式のテキストを含む拡張機能は、[3]の文字セットの使用に関するIETF方針に従って、そのテキストはUTF-8であることを許容しなければなりません。これは、SIPは、国際標準のままであることを保証します。一般的なガイドラインとして、自由形式のテキストは、プロトコル処理を実行するためのプログラムで必要とされることはありません。これは通常によって入力され、ユーザに表示されます。拡張子がUTF-8エンコードされた文字を含むことができ、パラメータを使用し、その拡張子が他のパラメータには、このパラメータで構成されるの比較を必要とする場合、比較は大文字と小文字を区別しなければなりません。 UTF-8テキストの大文字と小文字を区別しない比較の規則は、この時点では、不可能であり、避けなければなりません。
Extensions that make use of dates MUST use the SIP-Date BNF defined in RFC 3261. No other date formats are allowed. However, the usage of absolute dates to determine intervals (for example, the time at which some timer fires) is NOT RECOMMENDED. This is because it requires synchronized time between peers, and this is frequently not the case. Therefore, relative times, expressed in numbers of seconds, SHOULD be used.
日付を利用する拡張機能は、RFC 3261で定義されたSIP-日付BNF他の日付形式が許可されませんを使用しなければなりません。しかし、間隔を決定するために、絶対的な日付の使用は、（例えば、いくつかのタイマーが起動時間）が推奨されません。それは、ピア間で同期の時間を必要とするからであり、これは頻繁にそうではありません。したがって、相対時間は、秒数で表現使用すべきです。
Extensions that include network-layer addresses SHOULD permit dotted quad IPv4 addresses, IPv6 addresses in the format described in [4], and domain names.
ネットワーク層アドレスを含む拡張は[4]、およびドメイン名に記述されたフォーマットで点線クワッドIPv4アドレス、IPv6アドレスを可能にすべきです。
Extensions that have header fields containing URIs SHOULD be explicit about which URI schemes can be used in that header field. Header fields SHOULD allow the broadest set of URI schemes possible that are a match for the semantics of the header field.
URIを含むフィールドをヘッダーた拡張機能は、URIスキームは、そのヘッダフィールドに使用することができるかについて明示的であるべきです。ヘッダフィールドは、ヘッダフィールドのセマンティクスのために一致している可能URIスキームの最も広いセットを可能にすべきです。
Header fields MUST follow the standard formatting for SIP, defined as follows:
ヘッダーフィールドは以下のように定義され、SIPの標準的な書式設定をに従う必要があります。
header = header-name HCOLON header-value *(COMMA header-value) header-name = token header-value = value *(SEMI value-parameter) value-parameter = token [EQUAL gen-value] gen-value = token / host / quoted-string value = token / host / quoted-string
ヘッダ=ヘッダ名HCOLONヘッダ値*（COMMAヘッダ値）ヘッダ名=トークンヘッダ値=値×（SEMI値パラメータ）値パラメータ=トークン[EQUAL GEN-値] GEN-値=トークン/ホスト/引用符で囲まれた文字列値=トークン/ホスト/引用符で囲まれた文字列
In some cases, this form is not sufficient. That is the case for header fields that express descriptive text meant for human consumption. An example is the Subject header field in SIP [2]. In this case, an alternate form is:
いくつかのケースでは、このフォームは十分ではありません。つまり、人間の消費のために意図説明文を発現するヘッダフィールドの場合です。例では、SIP [2]で件名ヘッダフィールドです。この場合には、別の形式です。
header = header-name HCOLON [TEXT-UTF8-TRIM]
ヘッダ=ヘッダ名HCOLON [TEXT-UTF8-TRIM]
Developers of extensions SHOULD allow for extension parameters in their header fields.
エクステンションの開発者は、ヘッダフィールドでの拡張パラメータを可能にすべきです。
Header fields that contain a list of URIs SHOULD follow the same syntax as the Contact header field in SIP. Implementors are also encouraged to wrap these URI in angle brackets, "<" and ">", at all times. We have found this to be a frequently misimplemented feature.
URIのリストが含まれているヘッダーフィールドは、SIPにおけるContactヘッダーフィールドと同じ構文に従ってください。実装者はまた、すべての回で、角括弧でこれらのURIをラップすることを奨励、「<」と「>」されています。私たちは、これが頻繁にmisimplemented機能であることがわかってきました。
Beyond the compact form, there is no need to define compressed versions of header field values. Compression of SIP messages SHOULD be handled at lower layers, for example, using IP payload compression [18] or signalling compression [20].
コンパクトなフォームを超えて、ヘッダフィールド値の圧縮バージョンを定義する必要はありません。 SIPメッセージの圧縮IPペイロード圧縮を使用して、例えば、下位層で処理されるべきである[18]又は圧縮シグナリング[20]。
Syntax for header fields is expressed in Augmented Backus-Naur Form and MUST follow the format of RFC 4234 [5]. Extensions MUST make use of the primitive components defined in RFC 3261 [2]. If the construction for a BNF element is defined in another specification, it is RECOMMENDED that the construction be referenced rather than copied. The reference SHOULD include both the document and section number. All BNF elements must be either defined or referenced.
ヘッダフィールドの構文は、拡張バッカス正規形で表現され、RFC 4234のフォーマットに従わなければならない[5]。拡張機能は、RFC 3261で定義されたプリミティブコンポーネントを利用する必要があります[2]。 BNFの要素の構造が他の仕様で定義されている場合、構造が参照ではなくコピーすることが推奨されます。参照文書とセクション番号の両方を含むべきです。すべてのBNFの要素は、いずれかの定義または参照する必要があります。
It is RECOMMENDED that BNF be collected into a single section near the end of the document.
BNFは、文書の終わり近くに、単一のセクションに収集することが推奨されます。
All tokens and quoted strings are separated by explicit linear white space. Linear white space, for better or worse, allows for line folding. Extensions MUST NOT define new header fields that use alternate linear white space rules.
すべてのトークンと引用符で囲まれた文字列は、明示的なリニアホワイトスペースで区切られます。リニアホワイトスペースは、良くも悪くも、ライン折りたたみが可能になります。拡張機能は、代替線形空白のルールを使用し、新たなヘッダフィールドを定義してはなりません。
All SIP extensions MUST verify that any BNF productions that they define in their grammar do not conflict with any existing grammar defined in other SIP standards-track specifications.
すべてのSIPの拡張は、彼らが彼らの文法で定義したBNFの制作は、他のSIPの標準トラック仕様で定義された既存の文法と競合しないことを確かめなければなりません。
Developers of protocols often get caught up in syntax issues, without spending enough time on semantics. The semantics of a protocol are far more important. SIP extensions MUST clearly define the semantics of the extensions. Specifically, the extension MUST specify the behaviors expected of a UAC, UAS, and proxy in processing the extension. This is often best described by having separate sections for each of these three elements. Each section SHOULD step through the processing rules in temporal order of the most common messaging scenario.
プロトコルの開発者は、多くの場合、セマンティクスに十分な時間を費やすことなく、構文の問題に巻き込ま。プロトコルの意味論は、はるかに重要です。 SIPの拡張は明らかに拡張子の意味を定義しなければなりません。具体的には、拡張は、拡張を処理する際にUAC、UAS、およびプロキシの予想行動を指定しなければなりません。これは、しばしば最高のこれらの三つの要素のそれぞれに別々のセクションを持っていることによって説明されます。各セクションは、最も一般的なメッセージング・シナリオの時間的順序で処理ルールをステップべきです。
Processing rules generally specify actions to be taken (in terms of messages to be sent, variables to be stored, and rules to be followed) on receipt of messages and expiration of timers. If an action requires transmission of a message, the rule SHOULD outline requirements for insertion of header fields or other information in the message.
処理規則は、一般的に、メッセージ及びタイマーの満了を受けて（送信されるメッセージは、格納される変数、従うべきルールの観点で）取るべきアクションを指定します。アクションは、メッセージの送信を必要とする場合、ルールは、メッセージのヘッダフィールド又は他の情報を挿入するための要件の概要を説明すべきです。
The extension SHOULD specify procedures to be taken in exceptional conditions that are recoverable, or that require some kind of user intervention. Handling of unrecoverable errors does not require specification.
拡張機能は回復している例外的な条件で撮影するための手順を指定する必要があり、またはそれは、ユーザの介入のいくつかの種類が必要です。回復不能なエラーの処理は、仕様を必要としません。
The specification SHOULD contain a section that gives examples of call flows and message formatting. Extensions that define substantial new syntax SHOULD include examples of messages containing that syntax. Examples of message flows should be given to cover common cases and at least one failure or unusual case.
仕様は、コールフロー及びメッセージフォーマットの例を示しセクションを含むべきです。かなり新しい構文を定義する拡張機能は、その構文を含むメッセージの例を含むべきです。メッセージ・フローの例は一般的なケースと少なくとも一つの故障または異常なケースをカバーするために与えられるべきです。
For an example of how to construct a good examples section, see the message flows and message formatting defined in the Basic Call Flows specification [21]. Note that complete messages SHOULD be used. Be careful to include tags, Via header fields (with the branch ID cookie), Max-Forwards, Content-Lengths, Record-Route, and Route header fields. Example INVITE messages MAY omit session descriptions, and Content-Length values MAY be set to "..." to indicate that the value is not provided. However, the specification MUST explicitly call out the meaning of the "..." and explicitly indicate that session descriptions were not included.
良好な実施例のセクションを構築する方法の例については、メッセージ・フロー、メッセージが基本的なコールで定義された書式を参照して明細書[21]に流れます。完全なメッセージが使用されるべきであることに注意してください。 （分岐IDクッキー付き）ヘッダフィールド、マックス・フォワード、コンテンツ長、録音・ルート、およびRouteヘッダーフィールドを経由して、タグを含めるように注意してください。例INVITEメッセージは、セッション記述を省略することができ、コンテンツの長さの値は、「...」の値が提供されていないことを示すために設定されてもよいです。ただし、仕様は明示的に「...」の意味を呼び出して、明示的にセッション記述が含まれていなかったことを示す必要があります。
Too often, extension documents dive into detailed syntax and semantics without giving a general overview of operation. This makes understanding of the extension harder. It is RECOMMENDED that extensions have a protocol overview section that discusses the basic operation of the extension. Basic operation usually consists of the message flow, in temporal order, for the most common case covered by the extension. The most important processing rules for the elements in the call flow SHOULD be mentioned. Usage of the RFC 2119 [1] terminology in the overview section is NOT RECOMMENDED, and the specification should explicitly state that the overview is tutorial in nature only. This section SHOULD expand all acronyms, even those common in SIP systems, and SHOULD be understandable to readers who are not SIP experts. [27] provides additional guidance on writing good overview sections.
あまりにも頻繁に、拡張書類は、操作の一般的な概要を与えることなく、詳細な構文とセマンティクスに飛び込みます。これは難しい拡張子を理解します。拡張子が拡張の基本的な操作を説明したプロトコルの概要のセクションを持っていることが推奨されます。基本的な操作は、通常、拡張子によって覆われる最も一般的なケースのために、時間順に、メッセージフローで構成されています。コールフロー内の要素のための最も重要な処理ルールを挙げるべきです。 RFC 2119の使用方法は、[1]概要セクションの用語は推奨されません、および仕様は明示的な概要は、チュートリアルでは唯一の自然の中であることを明記してください。このセクションでは、ものも含め、共通のSIPシステムでは、すべての頭字語を展開する必要があり、SIPの専門家ではない読者に理解できるべきです。 [27]良い概要セクションの記述に関する追加的なガイダンスを提供します。
Documents that define new SIP extensions will invariably have IANA Considerations sections.
新しいSIP拡張を定義するドキュメントは常にIANAの考慮事項のセクションを持つことになります。
If your extension is defining a new event package, you MUST register that package. RFC 3265 [6] provides the registration template. See
あなたの拡張機能は、新しいイベントパッケージを定義している場合は、そのパッケージを登録する必要があります。 RFC 3265 [6]登録テンプレートを提供します。見る
[22] for an example of the registration of a new event package. As discussed in RFC 3427 [10], only standards-track documents can register new event-template packages. Both standards-track and informational specifications can register event packages.
新たなイベントパッケージの登録の例[22]。 RFC 3427 [10]で説明したように、唯一の標準トラック文書は、新しいイベント・テンプレート・パッケージを登録することができます。どちらもスタンダードトラックおよび情報の仕様は、イベントパッケージを登録することができます。
If your extension is defining a new header field, you MUST register that header field. RFC 3261 [2] provides a registration template. See Section 8.2 of RFC 3262 [23] for an example of how to register new SIP header fields. Both standards-track and informational P-header specifications can register new header fields [10].
あなたの拡張機能は、新しいヘッダフィールドを定義している場合は、そのヘッダフィールドを登録する必要があります。 RFC 3261 [2]登録テンプレートを提供します。新しいSIPヘッダフィールドを登録する方法の例については、RFC 3262 [23]のセクション8.2を参照。標準トラックと情報Pヘッダ仕様の両方が、新しいヘッダフィールド[10]を登録することができます。
If your extension is defining a new response code, you MUST register that response code. RFC 3261 [2] provides a registration template. See Section 6.4 of RFC 3329 [19] for an example of how to register a new response code. As discussed in RFC 3427 [10], only standards-track documents can register new response codes.
あなたの拡張機能は、新しい応答コードを定義している場合は、その応答コードを登録する必要があります。 RFC 3261 [2]登録テンプレートを提供します。新しい応答コードを登録する方法の例については、RFC 3329 [19]の6.4節を参照してください。 RFC 3427 [10]で説明したように、唯一の標準トラック文書は、新しい応答コードを登録することができます。
If your extension is defining a new SIP method, you MUST register that method. RFC 3261 [2] provides a registration template. See Section 10 of RFC 3311 [24] for an example of how to register a new SIP method. As discussed in RFC 3427 [10], only standards-track documents can register new methods.
あなたの拡張機能は、新しいSIPメソッドを定義している場合は、そのメソッドを登録する必要があります。 RFC 3261 [2]登録テンプレートを提供します。新しいSIPメソッドを登録する方法の例については、RFC 3311 [24]のセクション10を参照。 RFC 3427 [10]で説明したように、唯一の標準トラック文書は、新しいメソッドを登録することができます。
If your extension is defining a new SIP header field parameter, you MUST register that header field parameter per the guidelines in RFC 3968 [7]. Section 4.1 of that specification provides a template. Only IETF approved specifications can register new header field parameters. However, there is no requirement that these be standards track.
あなたの拡張機能は、新しいSIPヘッダフィールドのパラメータを定義している場合は、[7] RFC 3968のガイドラインあたりのヘッダーフィールドパラメータを登録する必要があります。その仕様のセクション4.1には、テンプレートを提供しています。唯一のIETF承認された仕様は、新たなヘッダフィールドパラメータを登録することができます。しかし、これらは標準トラックある必要はありません。
If your extension is defining a new SIP URI parameter, you MUST register that URI parameter per the guidelines in RFC 3969 [8]. Section 4.1 of that specification provides a template. Only standards-track documents can register new URI parameters.
あなたの拡張機能は、新しいSIP URIパラメータを定義している場合は、[8] RFC 3969のガイドラインあたりのURIパラメータを登録する必要があります。その仕様のセクション4.1には、テンプレートを提供しています。唯一の標準トラック文書は、新しいURIパラメータを登録することができます。
Many SIP extensions make use of option tags, carried in the Require, Proxy-Require, and Supported header fields. Section 4.1 discusses some of the issues involved in the usage of these header fields. If your extension does require them, you MUST register an option tag for your extension. RFC 3261 [2] provides a registration template. See Section 8.1 of RFC 3262 [23] for an example of how to register an option tag. Only standards-track RFCs can register new option tags.
多くのSIPの拡張が必要で運ばれ、オプションタグを利用して、プロキシ要求、およびサポートされているヘッダフィールド。 4.1節では、これらのヘッダフィールドの使用に関わる問題のいくつかを説明します。あなたの拡張機能がそれらを必要とする場合は、あなたの拡張のためのオプションタグを登録する必要があります。 RFC 3261 [2]登録テンプレートを提供します。オプションタグを登録する方法の例については、RFC 3262 [23]の8.1節を参照してください。唯一の標準化過程のRFCは、新しいオプションのタグを登録できます。
Some SIP extensions will require establishment of their own IANA registries. RFC 2434 [25] provides guidance on how and when IANA registries are established. For an example of how to set one up, see Section 6 of RFC 3265 [6] for an example.
いくつかのSIPの拡張は、独自のIANAレジストリの確立が必要になります。 RFC 2434 [25]はIANAレジストリが確立された方法と時期についてのガイダンスを提供します。 1つのアップの設定方法の例については、例えばRFC 3265 [6]のセクション6を参照。
An important decision to be made about the extension is its title. The title MUST indicate that the document is an extension to SIP. It is RECOMMENDED that the title follow the basic form of "A [summary of function] for the Session Initiation Protocol (SIP)", where the summary of function is a one- to three-word description of the extension. For example, if an extension defines a new header field, called Make-Coffee, for making coffee, the title would read, "Making Coffee with the Session Initiation Protocol (SIP)". It is RECOMMENDED that these additional words be descriptive rather than naming the header field. For example, the extension for making coffee should not be named "The Make-Coffee Header for the Session Initiation Protocol".
延長についてなされるべき重要な決定は、そのタイトルです。タイトルは、文書はSIPの拡張であることを示す必要があります。タイトルが機能の概要拡張の3ワードの説明に一次元で、「セッション開始プロトコル（SIP）のための[機能の概要]」の基本的な形式に従うことが推奨されます。拡張子がメイク・コーヒーと呼ばれる新しいヘッダフィールドを定義した場合、コーヒーを作るために、タイトルは「セッション開始プロトコル（SIP）でコーヒーを作る」、読んでいました。これらの追加の言葉ではなく、ヘッダフィールドに名前を付けるよりも記述することをお勧めします。たとえば、コーヒーを作るための拡張子は、「セッション開始プロトコルのためのメイク・コーヒーヘッダー」と命名するべきではありません。
For extensions that define new methods, an acceptable template for titles is "The Session Initiation Protocol (SIP) X Method" where X is the name of the method.
新しいメソッドを定義する拡張機能の場合、タイトルの許容可能なテンプレートは、「セッション開始プロトコル（SIP）Xメソッド」Xは、メソッドの名前です。
Note that the acronym SIP MUST be expanded in the titles of RFCs, as per [26].
頭字語SIPは、[26]に従って、RFCのタイトルに展開しなければならないことに留意されたいです。
Extensions that define new methods SHOULD take into consideration and discuss the following issues:
新しいメソッドを定義する拡張機能を考慮すると次の問題を議論する必要があります：
o Can it contain bodies? If so, what is the meaning of the presence of those bodies? What body types are allowed?
Oそれは体が含まれていることはできますか？その場合は、それらの団体の存在の意味は何ですか？どのようなボディタイプが許可されていますか？
o Can a transaction with this request method occur while another transaction, in the same and/or reverse direction, is in progress?
Oこのリクエストメソッドとの取引は、同じおよび/または逆方向に、進行中で、他のトランザクション中に発生することができますか？
o The extension MUST define which header fields can be present in requests of that method. It is RECOMMENDED that this information be represented as a new column of Table 2/3 of RFC 3261 [2]. The table MUST contain rows for all header fields defined in standards-track RFCs at the time of writing of the extension.
O拡張フィールドは、その方法のリクエスト中に存在することができるヘッダを定義しなければなりません。なお、この情報は、表の新しい列として表されることが推奨されているRFC 3261の2/3 [2]。テーブルには、拡張子の執筆時点で標準化過程のRFCで定義されたすべてのヘッダフィールドの行を含まなければなりません。
o Can the request be sent within a dialog, or does it establish a dialog?
Oリクエストはダイアログ内で送信することができます、またはそれは、ダイアログを確立していますか？
o Is it a target refresh request?
Oそれは、ターゲットリフレッシュ要求ですか？
o Extensions to SIP that define new methods MAY specify whether offers and answers can appear in requests of that method or its responses. However, those extensions MUST adhere to the protocol rules specified in [28] and MUST adhere to the additional constraints for offers and answers as specified in SIP [2].
O新しいメソッドを定義するSIPの拡張は、オファーとアンサーがそのメソッドまたはその応答の要求に表示できるかどうかを指定するかもしれません。しかし、これらの拡張機能は、[28]で指定されたプロトコルのルールに従わなければなりませんし、SIP [2]で指定されたオファーとアンサーのための追加の制約に準拠する必要があります。
o Because of the nature of reliability treatment of requests with new methods, those requests need to be answered immediately by the UAS. Protocol extensions that require longer durations for the generation of a response (such as a new method that requires human interaction) SHOULD instead use two transactions - one to send the request, and another in the reverse direction to convey the result of the request. An example of that is SUBSCRIBE and NOTIFY [6].
O新しいメソッドを持つ要求の信頼性の治療の性質なので、これらの要求はUASによってすぐに回答する必要があります。リクエストの結果を伝えるために、1つのリクエストを送信するために、逆方向に別の - （例えば、人間の相互作用を必要とする新しい方法として）応答の生成のためのより長い期間を必要とするプロトコルの拡張ではなく、二つのトランザクションを使用すべきです。それの例は、[6] SUBSCRIBE及びNOTIFYあります。
o The SIP specification [2] allows new methods to specify whether transactions using that new method can be canceled using a CANCEL request. Further study of the non-INVITE transaction [14] has determined that non-INVITE transactions must be completed as soon as possible. New methods must not plan for the transaction to pend long enough for CANCEL to be meaningful. Thus, new methods MUST declare that transactions initiated by requests with that method cannot be canceled. Future work may relax this restriction, at which point these guidelines will be revised.
SIP仕様O [2]新しい方法は、その新たなメソッドを使用して取引がキャンセル要求を使用してキャンセルすることができるかどうかを指定することを可能にします。非INVITEトランザクションのさらなる研究[14]は非INVITEトランザクションは、できるだけ早く完了しなければならないと判断しました。新しい方法は有意義であることをキャンセルするために十分な長保留に取引を計画してはなりません。このように、新しいメソッドは、そのメソッドを持つ要求によって開始されたトランザクションを取り消すことができないことを宣言しなければなりません。今後の課題は、これらのガイドラインが改訂される時点で、この制限を、リラックスすることがあります。
o New methods that establish a new dialog must discuss the impacts of forking. The design of such new methods should follow the pattern of requiring an immediate request in the reverse direction from the request establishing a dialog, similar to the immediate NOTIFY sent when a subscription is created per RFC 3265 [6].
O新しいダイアログを確立する新しい方法は、フォークの影響を議論する必要があります。このような新たな方法の設計は、サブスクリプションは、RFC 3265ごとに作成されたときに送信されたNOTIFY即時のようなダイアログを確立要求から逆方向の即時の要求を必要とするパターンに従うべきである[6]。
The reliability mechanisms for all new methods must be the same as for BYE. The delayed response feature of INVITE is only available in INVITE, never for new methods. The design of new methods must encourage an immediate response. If the application being enabled requires a delay, the design SHOULD follow a pattern using multiple transactions, similar to RFC 3265's use of NOTIFYs with different Subscription-State header field values (pending and active in particular) in response to SUBSCRIBE [6].
すべての新しいメソッドのための信頼性のメカニズムはBYEの場合と同じでなければなりません。 INVITEの遅延応答機能は、決して新しいメソッドのために、INVITEでのみ使用可能です。新しいメソッドの設計は、即時応答を奨励しなければなりません。有効にされているアプリケーションは、遅延を必要とする場合、設計は、[6] SUBSCRIBEに応答して（ペンディング特に活性）異なるサブスクリプションステートヘッダフィールド値とのNOTIFYのRFC 3265の使用と同様の複数のトランザクションを、使用パターンに従うべきです。
4.11. Additional Considerations for New Header Fields or Header Field Parameters
4.11. 新しいヘッダフィールドやヘッダーフィールドパラメータに関する追加の考慮事項
The most important issue for extensions that define new header fields or header field parameters is backwards compatibility. See Section 4.1 for a discussion of the issues. The extension MUST detail how backwards compatibility is addressed.
新しいヘッダフィールドやヘッダフィールドのパラメータを定義拡張のための最も重要な問題は、後方互換性です。問題の議論については、セクション4.1を参照してください。拡張MUST詳細どのように後方互換性が対処されます。
It is often tempting to avoid creation of a new method by overloading an existing method through a header field or parameter. Header fields and parameters are not meant to fundamentally alter the meaning of the method of the request. A new header field cannot change the basic semantic and processing rules of a method. There is no shortage of method names, so when an extension changes the basic meaning of a request, a new method SHOULD be defined.
多くの場合、ヘッダフィールドまたはパラメータを使用して既存のメソッドをオーバーロードして、新しいメソッドの作成を避けるために魅力的です。ヘッダーフィールドとパラメータは、基本的に要求する方法の意味を変更することを意味するものではありません。新たなヘッダフィールドは、方法の基本的な意味論的及び処理ルールを変更することはできません。そこメソッド名の不足がないので、拡張子が、要求の基本的な意味を変更した場合、新しいメソッドを定義する必要があります。
For extensions that define new header fields, the extension MUST define the request methods the header field can appear in, and what responses it can be used in. It is RECOMMENDED that this information be represented as a new row of Table 2/3 of RFC 3261 [2]. The table MUST contain columns for all methods defined in standards-track RFCs at the time of writing of the extension.
新しいヘッダフィールドを定義拡張のため、拡張は、要求メソッドを定義しなければならないヘッダフィールドは、で表示されることができ、どのような応答には、で使用することができる。この情報は、RFCの表2/3の新しい行として表現されることが推奨されます3261 [2]。テーブルには、拡張子の執筆時点で標準化過程のRFCで定義されているすべてのメソッドのための列が含まれていなければなりません。
Because SIP can run over UDP, extensions that specify the inclusion of large bodies (where large is several times the ethernet MTU) are frowned upon unless end-to-end congestion controlled transport can be guaranteed. If at all possible, the content SHOULD be included indirectly [9], even if congestion controlled transports are available.
SIPは、エンドツーエンドの輻輳制御輸送を保証することができない限り、眉をひそめている（大は数回イーサネットMTUをある）UDP、大きな体を含めることを指定する拡張子の上に実行することができますので。可能であれば、コンテンツは、輻輳制御トランスポートが利用可能である場合でも、[9]間接的に含まれるべきです。
Note that the presence of a body MUST NOT change the nature of the message. That is, bodies cannot alter the state machinery associated with processing a request of a particular method or a response.
体の存在は、メッセージの本質を変更しないでくださいことに注意してください。つまり、体は特定の方法又は応答の要求の処理に関連付けられた状態機械を変更することはできません。
Bodies enhance this processing by providing additional data.
ボディは、追加データを提供することによって、この処理を強化します。
We have observed that certain capabilities of SIP continually interact with extensions in unusual ways. Writers of extensions SHOULD consider the interactions of their extensions with these SIP capabilities and document any unusual interactions, if they exist. The following are the most common causes of problems:
私たちは、SIPの特定の機能が継続的に珍しい方法で拡張と対話することを観察しました。拡張子の作家は、これらのSIP機能を備えたその拡張子の相互作用を考慮し、それらが存在する場合には、異常な相互作用を文書化する必要があります。以下は、問題の最も一般的な原因です。
Forking: Forking by far presents the most troublesome interactions with extensions. This is generally because it can cause (1) a single transmitted request to be received by an unknown number of UASes, and (2) a single INVITE request to have multiple responses.
フォーク：これまでの拡張子を持つ最も厄介な相互作用を提示することによりフォーク。それは（1）単一の送信要求がUASesの未知数によって受信させることができる、及び（2）単一のINVITE要求は、複数の応答を持っているので、これは一般的です。
CANCEL and ACK: CANCEL and ACK are "special" SIP requests, in that they are exceptions to many of the general request processing rules. The main reason for this special status is that CANCEL and ACK are always associated with another request. New methods SHOULD consider the meaning of cancellation, as described above. Extensions that define new header fields in INVITE requests SHOULD consider whether they also need to be included in ACK and CANCEL. Frequently they do, in order to allow a stateless proxy to route the CANCEL or ACK identically to the INVITE.
CANCELとACK：CANCELとACKという点で、彼らは一般的な要求の処理ルールの多くの例外です、「特別な」SIPリクエストです。この特別な地位のための主な理由は、CANCELとACKは常に別の要求に関連付けられていることです。上記のように新しいメソッドは、キャンセルの意味を検討すべきです。 INVITEリクエストの新しいヘッダフィールドを定義する拡張機能は、彼らはまた、ACKに含まれる必要があるかどうかを検討し、中止されます。頻繁に彼らは、ルートへのステートレスプロキシを可能にするためにインクルードは、同一のINVITEにCANCELまたはACK。
Routing: The presence of Route header fields in a request can cause it to be sent through intermediate proxies. Requests that establish dialogs can be record-routed, so that the initial request goes through one set of proxies, and subsequent requests through a different set. These SIP features can interact in unusual ways with extensions.
ルーティング：リクエストにRouteヘッダフィールドの存在は、それが中間プロキシを介して送信させることができます。最初の要求が異なるセットを介してプロキシ、後続の要求の1セットを通過するようにダイアログを確立する要求は、記録的なルーティングすることができます。これらのSIP機能は、拡張子を持つ珍しい方法で対話することができます。
Stateless Proxies: SIP allows a proxy to be stateless. Stateless proxies are unable to retransmit messages and cannot execute certain services. Extensions that depend on some kind of proxy processing SHOULD consider how stateless proxies affect that processing.
ステートレスプロキシ：SIPプロキシはステートレスにすることができます。ステートレスプロキシは、メッセージを再送信することができず、特定のサービスを実行することはできません。プロキシ処理のいくつかの種類に依存拡張機能は、その処理にどのような影響を与えるかステートレスプロキシ検討すべきです。
Dialog Usages: SIP allows for requests that normally create their own dialog (such as SUBSCRIBE) to be used within a dialog created by another method (such as INVITE). In such a case, there are said to be multiple usages of that dialog. Extensions SHOULD consider their interaction with dialog usages. In particular, extensions that define new error response codes SHOULD describe whether that response code causes the dialog and all usages to terminate, or just a specific usage.
ダイアログ用途：SIPは、通常、（例えば、INVITEのような）他の方法で作成したダイアログ内で使用される（例えばSUBSCRIBEような）独自のダイアログを作成する要求を可能にします。そのような場合には、そのダイアログの複数の用途があると言われています。拡張機能は、ダイアログ用法との相互作用を考慮すべきです。具体的には、新しいエラー応答コードを定義する拡張子はその応答コードがダイアログと終了するすべての使用、または単に特定の使用を引き起こすかどうか記述する必要があります。
The nature of this document is such that it does not introduce any new security considerations. However, many of the principles described in the document affect whether a potential SIP extension design is likely to support the SIP security architecture.
この文書の性質は、それがどんな新しいセキュリティの考慮事項を導入しないようなものです。ただし、文書に記載されている原則の多くは、潜在的なSIP拡張の設計は、SIPのセキュリティアーキテクチャをサポートする可能性があるかどうかに影響します。
The authors would like to thank Rohan Mahy and Spencer Dawkins for their comments. Robert Sparks contributed important text on CANCEL issues. Thanks to Allison Mankin for her support.
作者は彼らのコメントのためローハンマーイとスペンサードーキンスに感謝したいと思います。ロバート・スパークスは、CANCEL問題に関する重要なテキストを寄付しました。彼女のサポートのためのアリソンマンキンに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] 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.
[2]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[3] Alvestrand、H.、BCP 18、RFC 2277 "文字セットと言語のIETF方針"、1998年1月。
[4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[4]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[5]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[6] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[6]ローチ、A.B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[7] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[7]キャマリロ、G.、BCP 98、RFC 3968、2004年12月 "セッション開始プロトコル（SIP）の番号機関（IANA）ヘッダーフィールドパラメータレジストリ割り当てインターネット"。
[8] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[8]カマリロ、G.、BCP 99、RFC 3969、2004年12月 "セッション開始プロトコル（SIP）のための番号機関（IANA）のURI（Uniform Resource Identifier）パラメータレジストリの割り当てインターネット"。
[9] Burger, E., Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[9]バーガー、E.、エド。、 "セッション開始プロトコル（SIP）におけるコンテンツの間接化の仕組みメッセージ"、RFC 4483、2006年5月を。
[10] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[10]マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼン、 "セッション開始プロトコル（SIP）のための変更処理"、BCP 67、RFC 3427、2002年12月。
[11] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[11] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[12]スパークス、R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月。
[13] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[13] RFC 4028 "セッション開始プロトコル（SIP）におけるセッションタイマー" ドノヴァン、S.およびJ.ローゼンバーグ、2005年4月。
[14] Sparks, R., "Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4321, January 2006.
[14]スパークス、R.、RFC 4321、2006年1月 "の問題は、セッション開始プロトコル（SIP）非INVITEトランザクションに関連する特定されました"。
[15] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[15]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[16] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[17] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[17]ハンドレー、M.、Schulzrinneと、H.、学生はE.、およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
[18] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
[18] Shacham、A.、Monsour、B.、ペレイラ、R。、およびM.トーマス、 "IPペイロード圧縮プロトコル（のIPComp）"、RFC 3173、2001年9月。
[19] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003.
[19] Arkko、J.、Torvinen、V.、カマリロ、G.、ニエミ、A.、およびT. Haukka、 "セッション開始プロトコル（SIP）のためのセキュリティメカニズム契約"、RFC 3329、2003年1月。
[20] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[20]価格、R.、ボルマン、C.、Christoffersson、J.、ハンヌ、H.、劉、Z.、およびJ.ローゼンバーグ、 "シグナリング圧縮（SigCompの）"、RFC 3320、2003年1月。
[21] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003.
[21]ジョンストン、A.、ドノバン、S.、スパークス、R.、カニンガム、C.、およびK.サマーズ、 "セッション開始プロトコル（SIP）の基本的なコールフローの例"、BCP 75、RFC 3665、2003年12月。
[22] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[22]ローゼンバーグ、J.、 "Aセッション開始プロトコル（SIP）登録のためのイベントパッケージ"、RFC 3680、2004年3月。
[23] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
、RFC 3262、2002年6月[23]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[24]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年10月。
[25] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
、BCP 26、RFC 2434、1998年10月[25] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[26] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", Work in Progress, July 2004.
[26]レイノルズ、J.、およびR.ブレーデン、 "コメント（RFC）作者の要求への指示"、進歩、2004年7月に作業。
[27] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.
[27]レスコラ、E.およびIAB、 "ライティングプロトコルモデル"、RFC 4101、2005年6月。
[28] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[28]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサン・ローゼンバーグシスコシステムズ600 Lanidexプラザパーシッパニー、NJ 07054米国
Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電話：+1 973 952-5000 Eメール：jdrosen@cisco.com URI：http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
ヘニングSchulzrinneとコロンビア大学のM / S 0401 1214アムステルダムアベニュー。ニューヨーク、NY 10027米国
EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs
電子メール：schulzrinne@cs.columbia.edu URI：http://www.cs.columbia.edu/~hgs
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。