[要約] RFC 4485は、SIPの拡張機能の作成者向けのガイドラインです。このRFCの目的は、SIPの拡張機能の作成に関するベストプラクティスを提供することです。
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)
セッション開始プロトコル（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).
Copyright（c）The Internet Society（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]は、インターネット全体でインタラクティブな通信セッションを確立するための柔軟でシンプルなツールです。この柔軟性の一部は、拡張できること（新しい方法、新しいヘッダーフィールド、新しいボディタイプ、新しいパラメーター）であり、それを行うために行われた無数の提案がありました。SIPプロトコルの拡張機能を定義するIETFプロセスが導入されています[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.
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"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は、モビリティ、構成と管理、QoSコントロール、コールコントロール、発信者の設定、デバイスコントロール、サードパーティのコールコントロール、MPLSパスセットアップなど、多くの問題のソリューションとして提案されています。明らかに、すべての問題が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拡張が問題の適切な解決策であるかどうかをエンジニアが決定するのを支援するために、2つの広範な基準を提示します。まず、問題は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アーキテクチャモデルに準拠しなければならないという2番目の基準は、プロトコルが管理可能で広く適用可能なままであることを保証します。
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の多くは、この発見とランデブー成分に焦点を当てています。フォークする能力、登録機能、およびそのルーティング機能はすべて、希望するユーザーがどこにいても希望するユーザーを見つけるという特異な目的のために存在します。そのため、個人のモビリティ、自動通話配信、Follow-MEなどの機能と機能は、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）シグナリングの交換として使用されることを意図していません。Integrated Services Digital Network（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メッセージは多くのホップ（各ホップがプロキシである）を横断すると想定されています。拡張機能は、単一のホップまたは専門的なネットワークトポロジの仮定の下でのみ機能してはなりません。彼らは単一のSIPプロバイダーの仮定を避けるべきです（ただし、RFC 3427 [10]ごとにPヘッダーの使用を参照してください）。
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.
プロキシは方法を理解する必要はありません。プロキシでのリクエストの処理は、よく知られているメソッド、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.
招待メッセージには完全な状態を伝えます：セッションの最初の招待メッセージは、セッションの何らかの特性を変更するための再入札メッセージとほぼ同じです（例外はタグです）。この完全な状態プロパティは、SIPの基本であり、SIPシステムの堅牢性にとって重要です。拡張機能は、機能を実行するために複数の招待状にまたがるデータを収集する必要があるように、招待処理を変更しないでください。
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.
Request URIは転送の主要なキーです。SIPサーバーでの転送ロジックは、主にリクエストURIに依存します（これは、ルートヘッダーフィールドを使用して中間プロキシを介してリクエストを渡すSIPのリクエストルーティングとは異なります）。SIPの操作の基本は、リクエストURIが通常の操作の下で、目的の受信者に解決するリソースを示していることです。拡張機能は、リクエスト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.
拡張機能が前のセクションでLitmusテストを満たしていることを考えると、すべての拡張機能を考慮すべきいくつかの問題があります。
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.
考慮すべき最も重要な問題の1つは、新しい拡張機能がベースライン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は、2つの方法のいずれかでこれを処理できます。最初に、リクエストは単に失敗し、サービスを提供できません。これは基本的に相互運用性の障害です。2番目のケースでは、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 プロキシリクイアヘッダーフィールドは、どんな犠牲を払っても避ける必要があります。個々のプロキシの障害の可能性は一定のままですが、パスの障害はホップ数とともに指数関数的に増加します。一方、要求ヘッダーフィールドは、単一のエンティティ、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.
新しいメソッドを定義する拡張機能では、要求ヘッダーフィールドを使用する必要はありません。SIPは、UACがUASによって新しい方法が理解されるかどうかをUACが知ることを可能にするメカニズムを定義します。これには、OptionsリクエストとAllow Headerフィールドを使用した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.
新しいメソッドを定義する拡張機能の逆方向の互換性を実現するために、許容ヘッダーフィールドが使用されます。新しいメソッドには、確立されたダイアログに使用されるもの（たとえば招待によって開始される）と、UAへの最初の要求として送信されるダイアログに使用される2つのタイプがあります。Inviteとその応答は両方とも許容ヘッダーフィールドを含める必要があるため、UAはダイアログ内で新しい方法をサポートできるかどうかを容易に判断できます。たとえば、招待ダイアログが確立されると、ユーザーエージェントは、許容ヘッダーフィールドに存在する場合、参照方法[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の両方を正しく実行する必要がある場合、要求の組み合わせとサポートされたメカニズムを使用する必要があります。サポートされているヘッダーフィールドが存在する場合、プロキシは要求に必要なヘッダーフィールドをリクエストに挿入できます。このような拡張機能の例は、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自体が使用するものとはまったく異なります。拡張機能は、2つを融合しないように注意する必要があります。ただし、メディアセッションに何らかの形で影響を与える拡張機能を定義する仕様では、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には、発信者、Callee、ユーザーエージェント、ヘッダーフィールドなどの用語を定義する広範な用語セクションがあります。すべての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％を超えることを意味します。これらの場合のコンパクトなフォームの使用は、メッセージオーバーヘッドを減らすためのより良いアプローチがあるため、5月にすぎません[20]。コンパクトヘッダーフィールドは単一の文字でなければなりません。26文字すべてが使い果たされると、新しいコンパクトなフォームが定義されなくなります。ヘッダーフィールド名は、RFC 3261、セクション25.1の「トークン」生産によって定義されるため、上限と小文字の文字、桁0〜9、ハイフン - マイナス（ - ）、フルストップ（。）、感嘆符（！）、パーセントサイン（％）、アスタリスク（*）、低線（_）、プラス記号（）、墓アクセント（ `）、アポストロフィ（ '）、およびティルド（〜）。それらは説明的であるが、かなり短いはずです。ヘッダーフィールド名はケースでは鈍感ですが、文書全体で単一の共通資本化を使用する必要があります。ヘッダーフィールド名に存在する各英語の単語が最初の文字を大文字にすることをお勧めします。たとえば、「thisisanewheader」。
As an example, the following are poor choices for header field names:
例として、以下はヘッダーフィールド名の選択肢が悪いものです。
ThisIsMyNewHeaderThatDoesntDoVeryMuchButItHasANiceName --.!A Function
thisismynewheaderthatdoesntddaymuchbutithasaniceName - 。！function
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規則と一致する必要があります。方法はケースに敏感でなければなりません。ヘッダーフィールド名は、ケースの鈍感でなければなりません。ヘッダーフィールドパラメーター名は、ケースの鈍感でなければなりません。ヘッダーフィールド値とパラメーター値は、ケースに敏感である場合があり、場合によっては症例が鈍感です。ただし、一般的に、それらは症例鈍感でなければなりません。ケースに敏感なコンポーネントを定義するには、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.
Freeformテキストを含む拡張機能は、文字セットの使用に関するIETFポリシーに従って、そのテキストをUTF-8にすることを許可する必要があります[3]。これにより、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-Date 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]で説明されている形式で点線のQuad 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
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]
header = header-name 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のコンタクトヘッダーフィールドと同じ構文をたどる必要があります。また、実装者は、これらのURIを角度ブラケット「<」と「>」で常に包むことをお勧めします。これは頻繁に誤った誤った機能であることがわかりました。
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.
ヘッダーフィールドの構文は、Backus-Naurの拡張形式で表され、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、およびプロキシに期待される動作を指定する必要があります。これは、これらの3つの要素のそれぞれに個別のセクションを持つことで、多くの場合、最もよく説明されます。各セクションは、最も一般的なメッセージングシナリオの時間的順序で処理ルールを踏み出す必要があります。
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.
仕様には、コールフローとメッセージフォーマットの例を示すセクションが含まれている必要があります。実質的な新しい構文を定義する拡張機能には、その構文を含むメッセージの例を含める必要があります。メッセージフローの例は、一般的なケースと少なくとも1つの障害または異常なケースをカバーするために与える必要があります。
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 Cookieを使用）、最大、コンテンツレングス、レコードルート、ルートヘッダーフィールドを介してタグを含めるように注意してください。招待のメッセージメッセージはセッションの説明を省略する場合があり、コンテンツレングスの値を「...」に設定して、値が提供されていないことを示します。ただし、仕様は「...」の意味を明示的に呼び出し、セッションの説明が含まれていないことを明示的に示している必要があります。
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-Header仕様の両方が、新しいヘッダーフィールドを登録できます[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ヘッダーフィールドパラメーターを定義している場合、RFC 3968のガイドラインに従ってそのヘッダーフィールドパラメーターを登録する必要があります[7]。その仕様のセクション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パラメーターを定義している場合、RFC 3969のガイドラインに従ってそのURIパラメーターを登録する必要があります[8]。その仕様のセクション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の拡張機能であることを示す必要があります。タイトルは、セッション開始プロトコル（SIP）の[機能の要約]の基本形式に従うことをお勧めします。ここで、関数の概要は拡張の1〜3ワードの説明です。たとえば、拡張機能がコーヒーを作るためにメイクコフィーと呼ばれる新しいヘッダーフィールドを定義する場合、タイトルは「セッション開始プロトコル（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].
[26]によると、頭字語SIPはRFCSのタイトルで拡張する必要があることに注意してください。
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]の表2/3の新しい列として表すことをお勧めします。テーブルには、拡張機能の作成時に標準トラックRFCSで定義されているすべてのヘッダーフィールドの行が含まれている必要があります。
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によってすぐに回答する必要があります。応答の生成に長い時間を必要とするプロトコル拡張（人間の相互作用を必要とする新しい方法など）は、2つのトランザクションを使用する必要があります。1つはリクエストを送信し、もう1つはリクエストの結果を伝えるために逆方向です。その例は、購読して通知[6]です。
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.
o SIP仕様[2]により、新しいメソッドを使用したトランザクションをキャンセル要求を使用してキャンセルできるかどうかを指定する新しいメソッドが可能になります。非インバイトトランザクション[14]のさらなる研究により、非インバイトトランザクションはできるだけ早く完了する必要があると判断されました。新しい方法は、キャンセルが意味のあるものになるのに十分な長さのトランザクションを計画してはなりません。したがって、新しい方法は、そのメソッドを使用したリクエストによって開始されたトランザクションをキャンセルできないことを宣言する必要があります。将来の作業はこの制限を緩和する可能性があり、その時点でこれらのガイドラインが改訂されます。
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 [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].
すべての新しい方法の信頼性メカニズムは、さようならと同じでなければなりません。招待の遅延応答機能は、招待状でのみ利用できますが、新しい方法ではありません。新しい方法の設計は、即時の対応を促進する必要があります。有効化されているアプリケーションに遅延が必要な場合、設計は、サブスクライブに応じて異なるサブスクリプションステートヘッダーフィールド値（特に保留中およびアクティブ）を持つRFC 3265の通知の使用と同様に、複数のトランザクションを使用してパターンに従う必要があります[6]。
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を参照してください。拡張機能は、後方互換性の対処方法を詳述する必要があります。
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はUDPを介して実行できるため、大きなボディ（大きい場合はイーサネットMTUの数倍）を指定する拡張機能が、エンドツーエンドの混雑制御輸送を保証できない限り、眉をひそめます。可能であれば、混雑制御された輸送が利用可能であっても、コンテンツを間接的に含める必要があります[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）未知の数のUASEによって（1）送信された要求を引き起こす可能性があるためです。
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.
キャンセルとACK：キャンセルとACKは、一般的な要求処理ルールの多くを例外とするという点で、「特別な」SIPリクエストです。この特別なステータスの主な理由は、キャンセルとACKが常に別のリクエストに関連付けられていることです。上記のように、新しい方法はキャンセルの意味を考慮する必要があります。招待リクエストで新しいヘッダーフィールドを定義する拡張機能は、ACKに含める必要があるかどうかを検討する必要があります。頻繁に、ステートレスプロキシがキャンセルまたは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.
ルーティング：リクエスト内のルートヘッダーフィールドの存在により、中間プロキシを介して送信される可能性があります。ダイアログを確立するリクエストは、記録的なルーティングを行うことができるため、最初のリクエストは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など）で作成されるリクエストを可能にします。そのような場合、そのダイアログの複数の使用法があると言われています。拡張機能は、ダイアログの使用との相互作用を考慮する必要があります。特に、新しいエラー応答コードを定義する拡張機能は、その応答コードがダイアログとすべての使用法を終了するかどうか、または特定の使用法のみを原因で説明する必要があります。
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.
著者は、コメントについてRohan MahyとSpencer Dawkinsに感謝したいと思います。ロバート・スパークスは、キャンセルの問題について重要なテキストを提供しました。アリソン・マンキンのサポートに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[3] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[4] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[5] Crocker、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] Roach、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] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）のための数字局（IANA）ヘッダーフィールドパラメーターレジストリ」、BCP 98、RFC 3968、2004年12月。
[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] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）のための数字権権（IANA）のユニフォームリソース識別子（URI）パラメーターレジストリを割り当てました」、BCP 99、RFC 3969、2004年12月。
[9] Burger, E., Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[9] Burger、E.、ed。、「セッション開始プロトコル（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] Mankin、A.、Bradner、S.、Mahy、R.、Willis、D.、Ott、J。、およびB. Rosen、「セッション開始プロトコルの変更プロセス（SIP）」、BCP 67、RFC 3427、12月2002年。
[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] Sparks、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] Donovan、S。およびJ. Rosenberg、「セッション開始プロトコル（SIP）のセッションタイマー」、RFC 4028、2005年4月。
[14] Sparks, R., "Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4321, January 2006.
[14] Sparks、R。、「セッション開始プロトコル（SIP）非インバイトトランザクションに関連する問題」、RFC 4321、2006年1月。
[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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-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.、Rao、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] Handley、M.、Schulzrinne、H.、Schooler、E。、およびJ. Rosenberg、「SIP：SESSION INTIATION Protocol」、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.、Pereira、R。、およびM. Thomas、「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.、Camarillo、G.、Niemi、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] Price、R.、Bormann、C.、Christoffersson、J.、Hannu、H.、Liu、Z。、およびJ. Rosenberg、「Signaling Compression（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] Johnston、A.、Donovan、S.、Sparks、R.、Cunningham、C。、およびK. Summers、「セッション開始プロトコル（SIP）基本的なコールフローの例」、BCP 75、RFC 3665、2003年12月。
[22] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[22] Rosenberg、J。、「登録のためのセッション開始プロトコル（SIP）イベントパッケージ」、RFC 3680、2004年3月。
[23] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[23] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[24] Rosenberg、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.
[25] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[26] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", Work in Progress, July 2004.
[26] Reynolds、J。and R. Braden、「コメント要求の指示（RFC）著者」、2004年7月、Working Progress。
[27] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.
[27] Rescorla、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステム600ラニデックスプラザパルシッパニー、ニュージャージー07054米国
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
ヘニングシュルツリンコロンビア大学M/S 0401 1214 AMSTERDAM AVE. NEW YORK、NY 10027 US
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。