Network Working Group C. Bormann
Request for Comments: 5049 Universitaet Bremen TZI
Category: Standards Track Z. Liu
Nokia Research Center
R. Price
EADS Defence and Security Systems Limited
G. Camarillo, Ed.
Ericsson
December 2007
Applying Signaling Compression (SigComp)
to the Session Initiation Protocol (SIP)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP and Session Description Protocol (SDP) static dictionary.
この文書では、シグナリング圧縮（SigCompの）は、このようなデフォルトの最小のSigCompパラメータ、コンパートメントと状態管理の値、およびTCP上にSigCompのいくつかの問題として、セッション開始プロトコル（SIP）に適用した場合に適用されるいくつかの詳細を記述します。 SIPで使用するためのSigCompの任意の実装は、このドキュメントとのSigCompに準拠し、それに加えて、SIPおよびセッション記述プロトコル（SDP）静的辞書をサポートしなければなりません。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Compliance with This Specification ..............................3
4. Minimum Values of SigComp Parameters for SIP/SigComp ............3
4.1. decompression_memory_size (DMS) for SIP/SigComp ............4
4.2. state_memory_size (SMS) for SIP/SigComp ....................4
4.3. cycles_per_bit (CPB) for SIP/SigComp .......................5
4.4. SigComp_version (SV) for SIP/SigComp .......................5
4.5. locally available state (LAS) for SIP/SigComp ..............5
5. Delimiting SIP Messages and SigComp Messages on the Same Port ...5
6. Continuous Mode over TCP ........................................6
7. Too-Large SIP Messages ..........................................7
8. SIP Retransmissions .............................................7
9. Compartment and State Management for SIP/SigComp ................7
9.1. Remote Application Identification ..........................8
9.2. Identifier Comparison Rules ...............................10
9.3. Compartment Opening and Closure ...........................11
9.4. Lack of a Compartment .....................................13
10. Recommendations for Network Administrators ....................13
11. Private Agreements ............................................14
12. Backwards Compatibility .......................................14
13. Interactions with Transport Layer Security (TLS) ..............14
14. Example .......................................................15
15. Security Considerations .......................................17
16. IANA Considerations ...........................................17
17. Acknowledgements ..............................................17
18. References ....................................................18
18.1. Normative References .....................................18
18.2. Informative References ...................................19
SigComp [RFC3320] is a solution for compressing messages generated by application protocols. Although its primary driver is to compress SIP [RFC3261] messages, the solution itself has been intentionally designed to be application agnostic so that it can be applied to any application protocol; this is denoted as ANY/SigComp. Consequently, many application-dependent specifics are left out of the base standard. It is intended that a separate specification be used to describe those specifics when SigComp is applied to a particular application protocol.
SigCompの[RFC3320]はアプリケーションプロトコルによって生成されたメッセージを圧縮するためのソリューションです。その主な要因は、SIP [RFC3261]メッセージを圧縮することであるが、溶液自体が意図的に任意のアプリケーションプロトコルに適用することができるように、アプリケーションにとらわれないように設計されています。これは、任意の/のSigCompと表記されます。その結果、多くのアプリケーション依存の仕様は、ベース標準から除外されています。別々の仕様はSigCompのは、特定のアプリケーションプロトコルに適用した場合、それらの詳細を説明するために使用されることが意図されます。
This document binds SigComp and SIP; this is denoted as SIP/SigComp.
この文書では、SigCompのとSIPを結合します;これは、SIP /のSigCompと表記されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Any SigComp implementation that is used for the compression of SIP messages MUST conform to this document, as well as to [RFC3320]. Additionally, it must support the SIP/SDP static dictionary, as specified in [RFC3485], and the mechanism for discovering SigComp support at the SIP layer, as specified in [RFC3486].
SIPメッセージの圧縮のために使用される任意のSigComp実装は、この文書に、ならびに[RFC3320]に従わなければなりません。 [RFC3486]で指定されるように、[RFC3485]で指定された、及びSIPレイヤでのSigCompサポートを発見するためのメカニズムとしてまた、それは、SIP / SDP静的辞書をサポートしなければなりません。
In order to support a wide range of capabilities among endpoints implementing SigComp, SigComp defines a few parameters to describe SigComp behavior (see Section 3.3 of [RFC3320]). For each parameter, [RFC3320] specifies a minimum value that any SigComp endpoint MUST support for ANY/SigComp. Those minimum values were determined with the consideration of all imaginable devices in which SigComp may be implemented. Scalability was also considered as a key factor.
SigCompのを実装するエンドポイント間の機能の広い範囲をサポートするために、SigCompのは（[RFC3320]のセクション3.3を参照）のSigCompの動作を説明するためのいくつかのパラメータを定義します。各パラメータは、[RFC3320]は、任意のSigComp終点はANY / SigCompのためにサポートしなければならない最小値を指定します。これらの最小値は、SigCompのを実装することができるすべての想像のデバイスを考慮して決定しました。拡張性も重要な要因と考えられました。
However, some of the minimum values specified in [RFC3320] are too small to allow good performance for SIP message compression. Therefore, they are increased for SIP/SigComp as specified in the following sections. For completeness, those parameters that are the same for SIP/SigComp as they are for ANY/SigComp are also listed.
しかしながら、[RFC3320]で指定された最小値の一部は、SIPメッセージ圧縮のための良好なパフォーマンスを可能にするには小さすぎます。したがって、それらは次のセクションで指定されたSIP / SigCompのために増加されます。完全にするために、彼らはANY / SigCompのためのものであるとして、SIP / SigCompのために同じであるそれらのパラメータも記載されています。
The new minimum values are specific to SIP/SigComp and, thus, do not apply to any other application protocols. A SIP/SigComp endpoint MAY offer additional resources over and above the minimum values specified in this document if available; these resources can be advertised to remote endpoints as described in Section 9.4.9 of [RFC3320].
新しい最小値は、SIP / SigCompのに固有のものであり、したがって、他のアプリケーションプロトコルには適用されません。 SIP / SigCompのエンドポイントは、利用可能な場合は、この文書で指定された最小値を越えて上方に追加のリソースを提供することができます。 [RFC3320]のセクション9.4.9に記載したように、これらのリソースは、リモートエンドポイントに通知することができます。
Minimum value for ANY/SigComp: 2048 bytes, as specified in Section 3.3.1 of [RFC3320].
ANY / SigCompのための最小値：2048バイト、[RFC3320]のセクション3.3.1で指定されるように。
Minimum value for SIP/SigComp: 8192 bytes.
SIP / SigCompのための最小値：8192バイト。
Reason: a DMS of 2048 bytes is too small for SIP message compression as it seriously limits the compression ratio and even makes compression impossible for certain messages. For example, the condition set by [RFC3320] for SigComp over UDP means: C + 2*B + R + 2*S + 128 < DMS (each term is described below). Therefore, if DMS is too small, at least one of C, B, R, or S will be severely restricted. On the other hand, DMS is memory that is only temporarily needed during decompression of a SigComp message (the memory can be reclaimed when the message has been decompressed). Therefore, a requirement of 8 KB should not cause any problems for an endpoint that already implements SIP, SigComp, and applications that use SIP.
理由：それは真剣に圧縮比を制限しても、特定のメッセージのために圧縮が不可能として2048バイトのDMSは、SIPメッセージの圧縮のためには小さすぎます。例えば、UDP上のSigCompのために[RFC3320]で設定された条件を意味する：C + 2 * B + R + 2 * S + 128 <DMS（各用語は以下に記載されています）。 DMSが小さすぎるため、、C、B、R、またはSの少なくとも1つが厳しく制限されます。一方、DMSのみ一時的にSigCompメッセージ（メッセージが解凍されたときにメモリを再利用することができる）の減圧時に必要とされるメモリです。そのため、8キロバイトの要件は、すでにSIP、SigCompの、およびSIPを使用するアプリケーションを実装してエンドポイントのいずれかの問題が発生することはありません。
C size of compressed application message, depending on R B size of bytecode. Note: two copies -- one as part of the SigComp message and one in UDVM (Universal Decompressor Virtual Machine) memory. R size of circular buffer in UDVM memory S any additional state uploaded other than that created from the content of the circular buffer at the end of decompression (similar to B, two copies of S are needed) 128 the smallest address in UDVM memory to copy bytecode to
バイトコードのR Bのサイズに応じて圧縮されたアプリケーションメッセージのCサイズ、。注意：二つのコピー - のSigCompメッセージの一部として1とUDVM（ユニバーサルデコンプレッサ仮想マシン）メモリの1を。 UDVMメモリS追加の状態は、（Sの2つのコピーが必要とされている、Bに類似）減圧の終わりに円形のバッファの内容から作成されたもの以外のアップロードにおける循環バッファのRサイズ128コピーするUDVMメモリの最小アドレスバイトコードへ
Minimum value for ANY/SigComp: 0 (zero) bytes, as specified in Section 3.3.1 of [RFC3320].
ANY / SigCompのための最小値：0（ゼロ）バイト、[RFC3320]のセクション3.3.1で指定されるように。
Minimum value for SIP/SigComp: 2048 bytes.
SIP / SigCompのための最小値：2048バイト。
Reason: a non-zero SMS allows an endpoint to upload a state in the first SIP message sent to a remote endpoint without the uncertainty of whether the remote endpoint will have enough memory to store such a state. A non-zero SMS obviously requires the SIP/SigComp implementation to keep state. Based on the observation that there is little gain from stateless SigComp compression, the assumption is that purely stateless SIP implementations are unlikely to provide a
理由：非ゼロのSMSは、エンドポイント、リモートエンドポイントがそのような状態を格納するための十分なメモリを持っているかどうかの不確実性なしにリモートエンドポイントに送信された第1のSIPメッセージの状態をアップロードすることを可能にします。非ゼロのSMSは明らかに状態を維持するためにSIP /のSigComp実装が必要です。ステートレスのSigComp圧縮から少し利得があるという観察に基づいて、仮定は純粋にステートレスSIP実装が提供する可能性は低いということです
SigComp function. Stateful implementations should have little problem to keep 2K additional state for each compartment (see Section 9).
SigCompの機能。ステートフル実装は各区画のための2K追加の状態を保つために少し問題を抱えている必要があります（セクション9を参照）。
Note: SMS is a parameter that applies to each individual compartment. An endpoint MAY offer different SMS values for different compartments as long as the SMS value is not less than 2048 bytes.
注意：SMSは、個々の区画に適用されるパラメータです。エンドポイントは、限りSMS値が2048バイト未満でないと異なる区画に異なるSMS値を提供することがあります。
Minimum value for ANY/SigComp: 16, as specified in Section 3.3.1 of [RFC3320].
[RFC3320]のセクション3.3.1で指定されるように16：ANY / SigCompのための最小値。
Minimum value for SIP/SigComp: 16 (same as above).
SIP / SigCompのための最小値：16（同上）。
For ANY/SigComp: 0x01, as specified in Section 3.3.2 of [RFC3320].
0x01の、[RFC3320]のセクション3.3.2で指定されるように：ANY / SigCompのため。
For SIP/SigComp: >= 0x02 (at least SigComp + NACK).
SIP / SigCompのため：> = 0x02の（少なくとものSigComp + NACK）。
Note that this implies that the provisions of [RFC4077] apply. That is, decompression failures result in SigComp NACK messages sent back to the originating compressor. It also implies that the compressor need not make use of the methods detailed in Section 2.4 of [RFC4077] (Detecting Support for NACK); for example, it can use optimistic compression methods right from the outset.
これは[RFC4077]の規定が適用されることを意味することに注意してください。これは、解凍の失敗が元の圧縮機に送り返されるのSigComp NACKメッセージが表示される、です。また、圧縮機（NACKのサポートを検出）[RFC4077]の2.4節に詳述した方法を使用しませ必要があることを意味します。例えば、それは右の最初から楽観的な圧縮方法を使用することができます。
Minimum LAS for ANY/SigComp: none, see Section 3.3.3 of [RFC3320].
ANY / SigCompのための最小LAS：なしは、[RFC3320]のセクション3.3.3を参照してください。
Minimum LAS for SIP/SigComp: the SIP/SDP static dictionary as defined in [RFC3485].
SIP / SigCompのための最小LAS：[RFC3485]で定義されるようにSIP / SDP静的辞書。
Note that, since support for the static SIP/SDP dictionary is mandatory, it does not need to be advertised.
静的なSIP / SDP辞書のサポートが必須であることから、それを宣伝する必要はありません、ということに注意してください。
In order to limit the number of ports required by a SigComp-aware endpoint, it is possible to allow both SigComp messages and 'vanilla' SIP messages (i.e., uncompressed SIP messages with no SigComp header) to arrive on the same port.
SigCompの対応エンドポイントによって必要なポートの数を制限するためには、両方のSigCompメッセージと「バニラ」SIPメッセージ（なしのSigCompヘッダを持つ、すなわち、非圧縮のSIPメッセージは）同じポートに到着させることができます。
For a message-based transport such as UDP or Stream Control Transmission Protocol (SCTP), distinguishing between SigComp and non-SigComp messages can be done per message. The receiving endpoint checks the first octet of the UDP/SCTP payload to determine whether the message has been compressed using SigComp. If the MSBs (Most Significant Bits) of the octet are "11111", then the message is considered to be a SigComp message and is parsed as per [RFC3320]. If the MSBs of the octet take any other value, then the message is assumed to be an uncompressed SIP message, and it is passed directly to the application with no further effect on the SigComp layer.
SigCompの非のSigCompメッセージを区別するようなUDPまたはストリーム制御伝送プロトコル（SCTP）のようなメッセージベースの輸送のためのメッセージごとに行うことができます。受信エンドポイントは、メッセージのSigCompを使用して圧縮されているかどうかを決定するためにUDP / SCTPペイロードの最初のオクテットをチェックします。オクテットのMSB（最上位ビット）が「11111」である場合、メッセージは、のSigCompメッセージであると考えられ、[RFC3320]に従って解析されます。オクテットの最上位ビットが任意の値を取る場合、メッセージは圧縮されていないSIPメッセージであると仮定され、それはSigCompの層には、さらに効果のあるアプリケーションに直接渡されます。
For a stream-based transport such as TCP, distinguishing between SigComp and non-SigComp messages has to be done per connection. The receiving endpoint checks the first octet of the TCP data stream to determine whether the stream has been compressed using SigComp. If the MSBs of the octet are "11111", then the stream is considered to contain SigComp messages and is parsed as per [RFC3320]. If the MSBs of the octet take any other value, then the stream is assumed to contain uncompressed SIP messages, and it is passed directly to the application with no further effect on the SigComp layer. Note that SigComp message delimiters MUST NOT be used if the stream contains uncompressed SIP messages.
SigCompの非SigCompのメッセージを区別するTCPのようなストリームベースの輸送については、接続ごとに行う必要があります。受信エンドポイントは、ストリームがのSigCompを使用して圧縮されているかどうかを決定するために、TCPデータストリームの最初のオクテットをチェックします。オクテットの最上位ビットが「11111」である場合、ストリームはSigCompのメッセージが含まれているとみなされ、[RFC3320]あたりとして解析されます。オクテットの最上位ビットが任意の値を取る場合は、ストリームが圧縮されていないSIPメッセージを含むと仮定され、それはSigCompの層には、さらに効果のあるアプリケーションに直接渡されます。ストリームが圧縮されていないSIPメッセージが含まれている場合のSigCompメッセージの区切り文字を使用してはいけないことに注意してください。
Applications MUST NOT mix SIP messages and SigComp messages on a single TCP connection. If the TCP connection is used to carry SigComp messages, then all messages sent over the connection MUST have a SigComp header and be delimited by the use of 0xFFFF, as described in [RFC3320].
アプリケーションは、単一のTCP接続上でSIPメッセージとのSigCompメッセージを混ぜてはなりません。 TCP接続がのSigCompメッセージを運ぶために使用されている場合は、接続を介して送信されたすべてのメッセージは、のSigCompヘッダーを持っていなければならず、[RFC3320]に記載されているように、0xFFFFでの使用によって区切られます。
Section 11 of [RFC4896] details a simple set of bytecodes, intended to be "well-known", that implement a null decompression algorithm. These bytecodes effectively allow SigComp peers to send selected SigComp messages with uncompressed data. If a SIP implementation has reason to send both compressed and uncompressed SIP messages on a single TCP connection, the compressor can be instructed to use these bytecodes to send uncompressed SIP messages that are also valid SigComp messages.
[RFC4896]のセクション11は、ヌル解凍アルゴリズムを実装する「既知」であることを意図しバイトコードの簡単なセットを、詳述します。これらのバイトコードは、効果的にSigCompピアが非圧縮データで選択のSigCompメッセージを送信することができます。 SIPの実装は、単一のTCP接続上の圧縮と非圧縮の両方のSIPメッセージを送信するための理由がある場合は、コンプレッサーにも有効なのSigCompメッセージで圧縮されていないSIPメッセージを送信するためにこれらのバイトコードを使用するように指示することができます。
Continuous Mode is a special feature of SigComp, which is designed to improve the overall compression ratio for long-lived connections. Its use requires pre-agreement between the SigComp compressor and decompressor. Continuous mode is not used with SIP/SigComp.
連続モードは、長寿命の接続のための全体的な圧縮率を改善するために設計されてSigCompの、の特別な機能です。その使用はSigCompの圧縮と解凍器間の事前の合意が必要です。連続モードは、SIP / SigCompのに使用されていません。
Reason: continuous mode requires the transport itself to provide a certain level of protection against denial-of-service attacks. TCP alone is not considered to provide enough protection.
理由：連続モードでは、サービス拒否攻撃に対する保護の一定のレベルを提供するために、トランスポート自体が必要です。単独のTCPは、十分な保護を提供すると考えられていません。
SigComp does not support the compression of messages larger than 64k. Therefore, if a SIP application sending compressed SIP messages to another SIP application over a transport connection (e.g., a TCP connection) needs to send a SIP message larger than 64k, the SIP application MUST NOT send the message over the same TCP connection. The SIP application SHOULD send the message over a different transport connection (to do this, the SIP application may need to establish a new transport connection).
SigCompのは、64Kを超えるメッセージの圧縮をサポートしていません。したがって、（例えば、TCP接続）トランスポート接続を介して別のSIPアプリケーションに圧縮されたSIPメッセージを送信するSIPアプリケーションは64Kよりも大きいSIPメッセージを送信する必要がある場合は、SIPアプリケーションが同一のTCP接続を介してメッセージを送ってはいけません。異なるトランスポート接続を介してメッセージを送信する必要がありますSIPアプリケーションは、（これを行うには、SIPアプリケーションは、新しいトランスポート接続を確立する必要があるかもしれません）。
When SIP messages are retransmitted, they need to be re-compressed, taking into account any SigComp states that may have been created or invalidated since the previous transmission. Implementations MUST NOT cache the result of compressing the message and retransmit such a cached result.
SIPメッセージが再送されている場合は、それらを考慮に前回の送信以降に作成または無効になっている可能性のあるのSigComp状態を取って、再圧縮する必要があります。実装は、メッセージを圧縮した結果をキャッシュして、そのようなキャッシュされた結果を再送してはなりません。
The reason for this behavior is that it is impossible to know whether the failure causing the retransmission occurred on the message being retransmitted or on the response to that message. If the response was lost, any state changes effected by the first instance of the retransmitted message would already have taken place. If these state changes removed a state that the previously transmitted message relied upon, then retransmission of the same compressed message would lead to a decompression failure.
この現象の理由は、再送信の原因となる障害が再送信されたメッセージまたはそのメッセージに対する応答に発生したかどうかを知ることは不可能であるということです。応答が失われた場合は、再送されたメッセージの最初のインスタンスによってもたらさどのような状態の変更がすでに行われているだろう。これらの状態変化が以前に送信されたメッセージが依拠した状態を削除した場合、その後、同じ圧縮されたメッセージの再送が伸張失敗につながります。
Note that a SIP retransmission may be caused by the original message or its response being lost by a decompression failure. In this case, a NACK will have been sent by the decompressor to the compressor, which may use the information in this NACK message to adjust its compression parameters. Note that, on an unreliable transport, such a NACK message may still be lost, so if a compressor used some form of optimistic compression, it MAY want to switch to a method less likely to cause any form of decompression failure when compressing a SIP retransmission.
SIP再送を減圧障害によって失われた元のメッセージまたは応答によって引き起こされ得ることに留意されたいです。この場合、NACKは、その圧縮パラメータを調整するために、このNACKメッセージ内の情報を使用することができる圧縮機に減圧装置によって送信されたであろう。信頼性の低いトランスポート上では、このようなNACKメッセージはまだ失われる可能性があることに注意してください、圧縮機は楽観的圧縮のいくつかのフォームを使用している場合、それはSIPの再送を圧縮する際に圧縮解除の失敗のいずれかの形式を起こしにくい方法に切り替えたいかもしれません。
An application exchanging compressed traffic with a remote application has a compartment that contains state information needed to compress outgoing messages and to decompress incoming messages. To increase the compression efficiency, the application must assign distinct compartments to distinct remote applications.
リモートアプリケーションで圧縮トラフィックを交換するアプリケーションは、発信メッセージを圧縮すると、受信メッセージを解凍するために必要な状態情報を含む区画を有します。圧縮効率を高めるために、アプリケーションは、別個のリモートアプリケーションに別個の区画を割り当てる必要があります。
SIP/SigComp applications identify remote applications by their SIP/ SigComp identifiers. Each SIP/SigComp application MUST have a SIP/ SigComp identifier URN (Uniform Resource Name) that uniquely identifies the application. Usage of a URN provides a persistent and unique name for the SIP/SigComp identifier. It also provides an easy way to guarantee uniqueness. This URN MUST be persistent as long as the application stores compartment state related to other SIP/SigComp applications.
SIP / SigCompのアプリケーションは、自分のSIP / SigCompの識別子でリモートアプリケーションを識別します。各SIP / SigCompのアプリケーションは、アプリケーションを一意に識別するSIP / SigCompの識別子URN（ユニフォームリソース名）が必要。 URNの使用方法は、SIP / SigCompの識別子のための永続的な、ユニークな名前を提供します。また、一意性を保証するための簡単な方法を提供します。このURNは、他のSIP / SigCompのアプリケーションに関連するアプリケーションを格納区画状態限り、永続的でなければなりません。
A SIP/SigComp application SHOULD use a UUID (Universally Unique IDentifier) URN as its SIP/SigComp identifier, due to the difficulties in equality comparisons for other kinds of URNs. The UUID URN [RFC4122] allows for non-centralized computation of a URN based on time, unique names (such as a Media Access Control (MAC) address), or a random number generator. If a URN scheme other than UUID is used, the URN MUST be selected such that the application can be certain that no other SIP/SigComp application would choose the same URN value.
SIP / SigCompのアプリケーションが原因のURNの他の種類の等価比較が困難に、そのSIP / SigCompの識別子としてUUID（汎用一意識別子）URNを使用すべきです。 UUID URN [RFC4122]は、時間に基づいて、URNの非集中型計算を可能にする、（例えば、メディアアクセス制御（MAC）アドレスのような）一意の名前、又は乱数発生器。 UUID URN以外の方式を使用する場合、URNは、アプリケーションが他のSIP / SigCompのアプリケーションが同じURN値を選択しないであろうことを確信することができるように選択されなければなりません。
Note that the definition of SIP/SigComp identifier is similar to the definition of instance identifier in [OUTBOUND]. One difference is that instance identifiers are only required to be unique within their AoR (Address of Record) while SIP/SigComp identifiers are required to be globally unique.
SIP / SigCompの識別子の定義は、[OUTBOUND]でインスタンス識別子の定義と同様であることに留意されたいです。一つの違いは、SIP / SigCompの識別子がグローバルに一意であることが要求されている間、インスタンス識別子は唯一彼らのAoR（レコードのアドレス）内で一意であることが要求されているということです。
Even if instance identifiers are only required to be unique within their AoR, devices may choose to generate globally unique instance identifiers. A device with a globally unique instance identifier SHOULD use its instance identifier as its SIP/SigComp identifier.
インスタンス識別子は、唯一自分のAoR内で一意であることが要求されている場合でも、デバイスは、グローバルに一意のインスタンス識別子を生成することもできます。グローバルに一意のインスタンス識別子を有するデバイスは、SIP / SigCompの識別子としてのインスタンス識別子を使用すべきです。
Note: Using the same value for an entity's instance and SIP/SigComp identifiers improves the compression ratio of header fields that carry both identifiers (e.g., a Contact header field in a REGISTER request).
注：エンティティのインスタンスとSIP / SigCompの識別子の同じ値を使用すると、両方の識別子を運ぶヘッダーフィールドの圧縮率を向上させることができる（例えば、REGISTER要求のContactヘッダフィールド）。
Server farms that share SIP/SigComp state across servers MUST use the same SIP/SigComp identifier for all their servers.
サーバー間でSIP / SigCompの状態を共有するサーバーファームは、すべてのサーバで同じSIP / SigCompの識別子を使用しなければなりません。
SIP/SigComp identifiers are carried in the 'sigcomp-id' SIP URI (Uniform Resource Identifier) or Via header field parameter. The 'sigcomp-id' SIP URI parameter is a 'uri-parameter', as defined by the SIP ABNF (Augmented Backus-Naur Form, Section 25.1 of [RFC3261]). The following is its ABNF [RFC4234]:
SIP / SigCompの識別子は「のSigComp-ID」SIP URI（ユニフォームリソース識別子）またはヘッダフィールドパラメータを介して搬送されます。 SIP ABNF（増補バッカスナウア記法、[RFC3261]のセクション25.1）によって定義されるように 'のSigComp-ID' SIP URIパラメータは、 'URIパラメータ' です。以下はそのABNF [RFC4234]です。
uri-sip-sigcomp-id = "sigcomp-id=" 1*paramchar
URI-SIP-のSigComp-ID = "SigCompの-ID =" 1 *のparamchar
The SIP URI 'sigcomp-id' parameter MUST contain a URN [RFC2141].
SIP URI 'のSigComp-ID' パラメータはURN [RFC2141]を含まなければなりません。
The Via 'sigcomp-id' parameter is a 'via-extension', as defined by the SIP ABNF (Section 25.1 of [RFC3261]). The following is its ABNF [RFC4234]:
SIP ABNF（[RFC3261]のセクション25.1）によって定義されるように 'を介してのSigComp-ID' パラメータは、 'を介して、拡張' です。以下はそのABNF [RFC4234]です。
via-sip-sigcomp-id = "sigcomp-id" EQUAL LDQUOT *( qdtext / quoted-pair ) RDQUOT
ビアSIP-のSigComp-ID = "のSigComp-ID" EQUAL LDQUOT *（qdtext /引用対）RDQUOT
The Via 'sigcomp-id' parameter MUST contain a URN [RFC2141].
'を介してのSigComp-ID' パラメータは、URN [RFC2141]を含まなければなりません。
The following is an example of a 'sigcomp-id' SIP URI parameter:
以下では「のSigComp-ID」SIP URIパラメータの一例です。
sigcomp-id=urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128
SigCompの-ID = URN：UUID：0C67446E-F1A1-11D9-94D3-000A95A0E128
The following is an example of a Via header field with a 'sigcomp-id' parameter:
以下では「のSigComp-ID」パラメータとViaヘッダーフィールドの例です。
Via: SIP/2.0/UDP server1.example.com:5060 ;branch=z9hG4bK87a7 ;comp=sigcomp ;sigcomp-id="urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128"
ビア：SIP / 2.0 / UDP server1.example.com:5060;ブランチ= z9hG4bK87a7; COMP =のSigComp; SigCompの-ID = "壷：UUID：0C67446E-F1A1-11D9-94D3-000A95A0E128"
The following is an example of a REGISTER request that carries 'sigcomp-id' parameters in a Via entry and in the Contact header field. Additionally, it also carries a '+sip.instance' Contact header field parameter.
以下は、ビアのエントリとContactヘッダフィールドに「のSigComp-ID」のパラメータを運ぶREGISTER要求の一例です。さらに、それはまた、「+ sip.instance」Contactヘッダーフィールドパラメータを運びます。
REGISTER sip:example.net SIP/2.0
Via: SIP/2.0/UDP 192.0.2.247:2078;branch=z9hG4bK-et736vsjirav;
rport;sigcomp-id="urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473"
From: "Joe User" <sip:2145550500@example.net>;tag=6to4gh7t5j
To: "Joe User" <sip:2145550500@example.net>
Call-ID: 3c26700c1adb-lu1lz5ri5orr
CSeq: 215196 REGISTER
Max-Forwards: 70
Contact: <sip:2145550500@192.0.2.247:2078;
sigcomp-id=urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473>;
q=1.0; expires=3600;
+sip.instance="<urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473>"
Content-Length: 0
SIP messages are matched with remote application identifiers as follows:
次のようにSIPメッセージは、リモートアプリケーション識別子と一致しています。
Outgoing requests: the remote application identifier is the SIP/ SigComp identifier of the URI to which the request is sent. If the URI does not contain a SIP/SigComp identifier, the remote application identifier is the IP address plus port of the datagram carrying the request for connectionless transport protocols, and the transport connection (e.g., a TCP connection) carrying the request for connection-oriented transport protocols (this is to support legacy SIP/SigComp applications).
発信要求：リモートアプリケーション識別子は、リクエストが送信されたURIのSIP / SigCompの識別子です。 URIは、SIP / SigCompの識別子が含まれていない場合は、リモートアプリケーション識別子は、connection-の要求を運ぶコネクションレスのトランスポートプロトコルの要求を運ぶデータグラム、およびトランスポート接続（例えば、TCP接続）のIPアドレスに加えてポートです指向のトランスポートプロトコル（これは、従来のSIP / SigCompのアプリケーションをサポートすることです）。
Incoming responses: the remote application identifier is the same as that of the previously sent request that initiated the transaction to which the response belongs.
着信応答：リモートアプリケーション識別子は、応答が属するトランザクションを開始し、以前に送信された要求の場合と同様です。
Incoming requests: the remote application identifier is the SIP/ SigComp identifier of the top-most Via entry. If the Via header field does not contain a SIP/SigComp identifier, the remote application identifier is the source IP address plus port of the datagram carrying the request for connectionless transport protocols, and the transport connection (e.g., a TCP connection) carrying the request for connection-oriented transport protocols (this is to support legacy SIP/SigComp applications).
着信要求：リモートアプリケーション識別子エントリ経由最上位のSIP / SigCompの識別子です。 Viaヘッダーフィールドは、SIP / SigCompの識別子が含まれていない場合は、リモートアプリケーション識別子は、要求を運ぶコネクションレスのトランスポートプロトコルの要求を運ぶデータグラム、およびトランスポート接続（例えば、TCP接続）の送信元IPアドレスとポートです接続指向のトランスポートプロトコルのために（これは、従来のSIP / SigCompのアプリケーションをサポートすることです）。
Outgoing responses: the remote application identifier is the same as that of the previously received request that initiated the transaction to which the response belongs. Note that, due to standard SIP Via header field processing, this identifier will be present in the top-most Via entry in such responses (as long as it was present in the top-most Via entry of the previously received request).
発信応答：リモートアプリケーション識別子は、応答が属するトランザクションを開始し、以前に受信された要求と同じです。ヘッダーフィールドの処理を介してによる標準SIPに、なお、この識別子は、（あれば、以前に受信した要求のエントリを介して最上位に存在したように）そのような応答のエントリビア最上位に存在するであろう。
A SIP/SigComp application placing its URI with the 'comp=sigcomp' parameter in a header field MUST add a 'sigcomp-id' parameter with its SIP/SigComp identifier to that URI.
ヘッダフィールドに「COMP = SigCompの」パラメータでそのURIを確定SIP / SigCompのアプリケーションは、そのURIに対するSIP / SigCompの識別子に「のSigComp-ID」パラメータを追加しなければなりません。
A SIP/SigComp application generating its own Via entry containing the 'comp=sigcomp' parameter MUST add a 'sigcomp-id' parameter with its SIP/SigComp identifier to that Via entry.
「COMP = SigCompの」パラメータを含む独自のViaエントリを生成するSIP / SigCompのアプリケーションがエントリを介してそれへのSIP / SigCompの識別子に「のSigComp-ID」パラメータを追加しなければなりません。
A given remote application identifier is mapped to a particular SigComp compartment ID following the rules given in Section 9.3.
特定のリモートアプリケーション識別子は、セクション9.3で与えられた規則に従って特定のSigComp区画IDにマッピングされます。
Equality comparisons between SIP/SigComp identifiers are performed using the rules for URN equality that are specific to the scheme in the URN. If the element performing the comparisons does not understand the URN scheme, it performs the comparisons using the lexical equality rules defined in RFC 2141 [RFC2141]. Lexical equality may result in two URNs being considered unequal when they are actually equal. In this specific usage of URNs, the only element that provides the URN is the SIP/SigComp application identified by that URN. As a result, the SIP/SigComp application SHOULD provide lexically equivalent URNs in each registration it generates. This is likely to be normal behavior in any case; applications are not likely to modify the value of their SIP/SigComp identifiers so that they remain functionally equivalent yet lexicographically different from previous identifiers.
SIP / SigCompの識別子との間の等価比較はURNでスキームに固有のURN平等のルールを使用して実行されます。比較を実行する要素はURN方式を理解していない場合、それは[RFC2141] RFC 2141で定義された語彙等価規則を使用して比較を行います。字句平等は、彼らが実際に等しい場合に等しくないと見なされている2つのURNをもたらすことができます。 URNのこの特定の使用では、URNを提供する唯一の要素は、そのURNによって識別されるSIP / SigCompのアプリケーションです。結果として、SIP / SigCompのアプリケーションは、それが生成する各登録における字句等価のURNを提供すべきです。これは、どのような場合でも正常な行動である可能性が高いです。彼らはまだ、以前の識別子と辞書的に異なる機能的に同等の残るようなアプリケーションは、自分のSIP / SigCompの識別子の値を変更する可能性はありません。
SIP applications need to know when to open a new compartment and when to close it. The lifetime of SIP/SigComp compartments is linked to registration state. Compartments are opened at SIP registration time and are typically closed when the registration expires or is canceled.
SIPアプリケーションは、新しいコンパートメントを開き、ときにそれを閉じるようにするとき知っておく必要があります。 SIP / SigCompの区画の寿命は、登録状態にリンクされています。区画は、SIP登録時に開かれ、登録の有効期限が切れるか、キャンセルされた場合、典型的には閉じられています。
Note: Linking the lifetime of SIP/SigComp compartments to registration state limits the applicability of this specification. In particular, SIP user agents that do not register but, for example, only handle PUBLISH or SUBSCRIBE/NOTIFY transactions are not able create SIP/SigComp compartments following this specification. Previous revisions of this specification also defined compartments valid during a SIP transaction or a SIP dialog. Those compartments covered all possible SIP entities, including those that do not handle REGISTER transactions. However, it was decided to eliminate those types of compartments because the complexity they introduced (e.g., edge proxy servers were required to keep dialog state) was higher than the benefits they brought in most deployment scenarios.
注：登録状態にSIP / SigCompの区画の寿命をリンクするこの仕様の適用性を制限します。具体的には、登録したが、例えば、唯一のPUBLISHまたはSUBSCRIBE / NOTIFYトランザクションを処理していないSIPユーザエージェントは、この仕様以下のSIP / SigCompの区画を作成することができません。この仕様の以前のリビジョンもSIPトランザクションまたはSIPダイアログの間に有効なコンパートメントを定義しました。これらのコンパートメントは、REGISTERのトランザクションを処理していないものも含め、すべての可能なSIPエンティティを、カバーしました。しかし、それは彼らが導入された複雑さは（例えば、エッジプロキシサーバは、対話状態を維持するために必要とされた）ので、区画のこれらのタイプを排除するために、彼らはほとんどの展開シナリオにもたらした恩恵よりも高くして決定されました。
Usually, any states created during the lifetime of a compartment will be "logically" deleted when the compartment is closed. As described in Section 6.2 of [RFC3320], a logical deletion can become a physical deletion only when no compartment continues to exist that created the (same) state.
区画が閉じられたときに通常、コンパートメントの存続期間中に作成された状態は「論理的に」削除されます。 [RFC3320]のセクション6.2で説明したように、論理的削除がない区画が（同じ）状態を作成し、その存在し続けていない唯一の物理的削除になることができます。
A SigComp endpoint may offer to keep a state created upon request from a SigComp peer endpoint beyond the default lifetime of a compartment (i.e., beyond the duration of its associated registration). This may be used to improve compression efficiency of subsequent SIP messages generated by the same remote application at the SigComp peer endpoint. To indicate that such state will continue to be available, the SigComp endpoint can inform its peer SigComp endpoint by announcing the (partial) state ID in the returned SigComp parameters at the end of the registration that was supposed to limit the lifetime of the SigComp state. That signals the state will be maintained. The mandatory support for the SigComp Negative
SigComp終点（すなわち、それに関連する登録の存続期間を超えて）区画のデフォルトの寿命を超えてのSigCompピアエンドポイントからの要求に応じて作成された状態を維持するために提供することができます。これは、SigCompのピアエンドポイントで同じリモートアプリケーションによって生成された後続のSIPメッセージの圧縮効率を向上させるために使用されてもよいです。このような状態が使用可能であり続けることを示すために、のSigComp終点はSigCompの状態の寿命を制限するようになっていた登録の終了時に返却のSigCompパラメータの（部分的な）状態IDを発表することによって、そのピアのSigComp終点を知らせることができます。その状態が維持される信号。 SigComp負の必須サポート
Acknowledgement (NACK) Mechanism [RFC4077] in SIP/SigComp ensures that it is possible to recover from synchronization errors regarding compartment lifetimes.
SIP /のSigCompにおいて肯定応答（NACK）メカニズム[RFC4077]は、区画寿命に関する同期エラーから回復することが可能であることを保証します。
As an operational concern, bugs in the compartment management implementation are likely to lead to sporadic, hard-to-diagnose failures. Decompressors may therefore want to cache old state and, if still available, allow access while logging diagnostic information. Both compressors and decompressors use the SigComp Negative Acknowledgement (NACK) Mechanism [RFC4077] to recover from situations where such old state may no longer be available.
運用の懸念として、コンパートメントの管理の実装のバグは散発的、ハード・ツー・診断の障害につながる可能性があります。デコンプレッサは、したがって、古い状態をキャッシュして、まだ利用可能な場合、診断情報をログに記録しながら、アクセスを許可することができます。両方のコンプレッサとデコンプレッサは、古い状態がもはや利用可能でないかもしれない状況から回復するためのSigComp否定応答（NACK）メカニズム[RFC4077]を使用します。
A REGISTER transaction causes an application to open a new compartment to be valid for the duration of the registration established by the REGISTER transaction.
REGISTERトランザクションは、REGISTERトランザクションによって確立された登録の期間中に有効であることを新たにコンパートメントを開くためのアプリケーションが発生します。
A SIP application that needs to send a compressed SIP REGISTER (i.e., a user agent generating a REGISTER or a proxy server relaying one to its next hop) SHOULD open a compartment for the request's remote application identifier. A SIP application that receives a compressed SIP REGISTER (i.e., the registrar or a proxy relaying the REGISTER to its next-hop) SHOULD open a compartment for the request's remote application identifier.
圧縮されたSIP REGISTERを送信する必要があるSIPアプリケーションは、（REGISTERまたはその次のホップに1を中継するプロキシサーバを生成する、すなわち、ユーザエージェント）要求のリモートアプリケーション識別子のための区画を開きます。圧縮されたSIP REGISTERを受信したSIPアプリケーション（すなわち、レジストラまたはその次のホップにREGISTERを中継するプロキシ）は、要求のリモートアプリケーション識別子のための区画を開きます。
These compartments MAY be closed if the REGISTER request is responded with a non-2xx final response, or when the registration expires or is canceled. However, applications MAY also choose to keep these compartments open for a longer period of time, as discussed previously. For a given successful registration, applications SHOULD NOT close their associated compartments until the registration is over.
登録の有効期限が切れたか、キャンセルされたときREGISTERリクエストが非2xxの最終応答で応答し、またはされている場合は、これらのコンパートメントは、閉鎖することができます。ただし、アプリケーションはまた、前述したように、時間の長い期間のために開いているこれらの区画を維持するために選ぶかもしれません。登録が終わるまで一定登録が成功するために、アプリケーションは、それらに関連するコンパートメントを閉じるべきではありません。
Note: A SIP network can be configured so that regular SIP traffic to and from a user agent traverses a different set of proxies than the initial REGISTER transaction. The path the REGISTER transaction follows is typically determined by configuration data. The path subsequent requests traverse is determined by the Path [RFC3327] and the Service-Route [RFC3308] header fields in the REGISTER transaction and by the Record-Route and the Route header fields in dialog-creating transactions. Previous revisions of this document supported the use of different paths for different types of traffic. However, for simplicity reasons, this document now assumes that networks using compression will be configured so that subsequent requests follow the same path as the initial REGISTER transaction in order to achieve the best possible compression. Section 10 provides network administrators with recommendations so that they can configure the networks properly.
注：ユーザー・エージェントへとから、通常のSIPトラフィックが最初のREGISTERの取引よりもプロキシの異なるセットを横断するようにSIPネットワークを構成することができます。 REGISTERトランザクションは、以下の経路は、典型的には、コンフィギュレーションデータによって決定されます。後続の要求は、横断パスはパス[RFC3327]とレジスタトランザクションおよびレコードルートとダイアログ作成トランザクションでRouteヘッダフィールドによってサービス・ルート[RFC3308]のヘッダフィールドによって決定されます。このドキュメントの以前のリビジョンは、トラフィックの種類ごとに異なるパスを使用することを支持しました。しかし、単純化の理由から、このドキュメントは現在の圧縮を使用してネットワークが後続の要求は、可能な限り最高の圧縮を実現するために、最初のREGISTERトランザクションと同じ道をたどることになるように構成されることを前提としています。それらが適切にネットワークを構成できるように、セクション10は、勧告をネットワーク管理者に提供します。
If, following the rules above, a SIP application is supposed to open a compartment for a remote application identifier for which it already has a compartment (e.g., the SIP application registers towards a second registrar using the same edge proxy server as for its registration towards its first registrar), the SIP application MUST use the already existing compartment. That is, the SIP application MUST NOT open a new compartment.
上記の規則に従って、SIPアプリケーションは、それがすでに区画を持っているリモートアプリケーション識別子（例えば、SIPアプリケーションが向かってその登録と同じエッジプロキシサーバを使用して第2のレジストラに向けて登録するためのコンパートメントを開くことになっている場合その最初のレジストラ）、SIPアプリケーションは、既存の区画を使用しなければなりません。つまり、SIPアプリケーションが新しいコンパートメントを開けてはなりません。
The use of stateless compression (i.e., compression without a compartment) is not typically worthwhile and may even result in message expansion. Therefore, if a SIP application does not have a compartment for a message it needs to send, it MAY choose not to compress it even in the presence of the 'comp=sigcomp' parameter. Section 5 describes how a SIP application can send compressed and uncompressed messages over the same TCP connection. Note that RFC 3486 [RFC3486] states the following:
ステートレス圧縮（区画無し即ち、圧縮）の使用は、典型的には、価値がないとさえメッセージ拡張をもたらすことができます。 SIPアプリケーションは、それが送信する必要があるメッセージのコンパートメントを持っていない場合、したがって、それも「COMP = SigCompの」パラメータの存在で、それを圧縮しないことを選択することができます。第5節では、SIPアプリケーションが同じTCP接続を介して、圧縮と非圧縮メッセージを送信する方法について説明します。なお、RFC 3486 [RFC3486]は以下のように述べています：
"If the next-hop URI contains the parameter comp=sigcomp, the client SHOULD compress the request using SigComp".
「ネクストホップURIは、パラメータCOMP =のSigCompが含まれている場合、クライアントはのSigCompを使用して要求を圧縮すべきです」。
Experience since RFC 3486 [RFC3486] was written has shown that stateless compression is, in most cases, not worthwhile. That is why it is not recommended to use it any longer.
書かれたRFC 3486 [RFC3486]以来の経験は、ほとんどの場合、価値がない、ステートレス圧縮であることを示しています。もはやそれを使用することは推奨されていない理由です。
Network administrators can configure their networks so that the compression efficiency achieved is increased. The following recommendations help network administrators perform their task.
達成される圧縮効率が増加するようにネットワーク管理者は、自社のネットワークを構成することができます。以下の推奨事項は、ネットワーク管理者は、自分のタスクを実行するのに役立ちます。
For a given user agent, the route sets for incoming requests (created by a Path header field) and for outgoing requests (created by a Service-Route header field) are typically the same. However, registrars can, if they wish, insert proxies in the latter route that do not appear in the former route and vice versa. It is RECOMMENDED that registrars are configured so that proxies performing SigComp compression appear in both routes.
所与のユーザエージェントは、（サービスルートヘッダフィールドによって作成された）（パスヘッダフィールドによって作成された）着信要求および発信要求のルート設定は、典型的には同じです。しかし、レジストラが、彼らが望むなら、かつてのルートおよびその逆に表示されません後者のルートにプロキシを挿入することができます。 SigCompの圧縮を行うプロキシは両方のルートに表示されるようにレジストラが設定されていることが推奨されます。
The routes described previously apply to requests sent outside a dialog. Requests inside a dialog follow a route constructed using Record-Route header fields. It is RECOMMENDED that the proxies performing SigComp that are in the route for requests outside a dialog are configured to place themselves (by inserting themselves in the Record-Route header fields) in the routes used for requests inside dialogs.
前述のルートは、ダイアログ外で送信された要求に適用されます。ダイアログ内のリクエストは、Record-Routeヘッダフィールドを使用して構築経路をたどります。ダイアログ外リクエストのルートにあるのSigCompを行うプロキシはダイアログ内のリクエストのために使用される経路で（Record-Routeヘッダフィールドに自身を挿入することによって）自分自身を配置するように構成されていることが推奨されます。
When a user agent's registration expires, proxy servers performing compression may close their associated SIP/SigComp compartment. If the user agent is involved in a dialog that was established before the registration expired, subsequent requests within the dialog may not be compressed any longer. In order to avoid this situation, it is RECOMMENDED that user agents are registered as long as they are involved in a dialog.
ユーザーエージェントの登録が終了すると、圧縮を行うプロキシサーバは、それに関連するSIP / SigCompのコンパートメントを閉じることができます。ユーザーエージェントは、登録の期限が切れる前に設立されたダイアログに関与している場合は、ダイアログ内の後続の要求はもはや圧縮されない場合があります。このような状況を避けるために、彼らが、ダイアログに関与しているように、ユーザエージェントは限り登録されていることが推奨されます。
SIP/SigComp implementations that are subject to private agreements MAY deviate from this specification, if the private agreements unambiguously specify so. Plausible candidates for such deviations include:
民間の契約が明確にそう指定した場合、民間協定の対象となるSIP / SigCompの実装は、この仕様から外れてもよいです。そのような偏差のためのもっともらしい候補者は、次のとおりです。
o Minimum values (Section 4). o Use of continuous mode (Section 6). o Compartment definition (Section 9).
Oの最小値（第4章）。連続モード（第6節）のOを使用。 Oコンパートメントの定義（第9節）。
SigComp has a number of parameters that can be configured per endpoint. This document specifies a profile for SigComp when used for SIP compression that further constrains the range that some of these parameters may take. Examples of this are Decompressor Memory Size, State Memory Size, and SigComp Version (support for NACK). Additionally, this document specifies how SIP/SigComp applications should perform compartment mapping.
SigCompのエンドポイントごとに設定可能なパラメータの数を有しています。この文書では、さらに、これらのパラメータの一部が取り得る範囲を制約するSIP圧縮に使用SigCompのためのプロファイルを指定します。この例は、デコンプレッサメモリサイズ、状態メモリサイズ、およびSigCompのバージョン（NACKのためのサポート）です。また、この文書は、SIP / SigCompのアプリケーションはコンパートメントのマッピングを実行する方法を指定します。
When this document was written, there were already a few existing SIP/SigComp deployments. The rules in this document have been designed to maximize interoperability with those legacy SIP/SigComp implementations. Nevertheless, implementers should be aware that legacy SIP/SigComp implementations may not conform to this specification. Examples of problems with legacy applications would be smaller DMS than mandated in this document, lack of NACK support, or a different compartment mapping.
この文書が書かれたときは、すでにいくつかの既存のSIP / SigCompの展開がありました。この文書に記載されているルールは、これらのレガシーSIP / SigCompの実装との相互運用性を最大化するように設計されています。それにもかかわらず、実装者はレガシーSIP / SigCompの実装は、この仕様に準拠していない可能性があることに注意する必要があります。レガシーアプリケーションとの問題の例としては、本文書に義務付けよりも小さいDMS、NACKのサポートの欠如、または異なるコンパートメントのマッピングになります。
Endpoints exchanging SIP traffic over a TLS [RFC4346] connection can use the compression provided by TLS. Two endpoints exchanging SIP/ SigComp traffic over a TLS connection that provides compression need to first compress the SIP messages using SigComp and then pass them to the TLS layer, which will compress them again. When receiving data, the processing order is reversed.
TLS [RFC4346]接続を介してSIPトラフィックを交換エンドポイントはTLSによって提供される圧縮を使用することができます。圧縮を提供するTLS接続を介してSIP /のSigCompトラフィックを交換する2つのエンドポイントは、最初のSigCompを用いてSIPメッセージを圧縮し、再度それらを圧縮するTLS層に渡す必要があります。データを受信した場合、処理の順序が逆になります。
However, compressing messages this way twice does not typically bring significant gains. Once a message is compressed using SigComp, TLS is not usually able to compress it further. Therefore, TLS will normally only be able to compress SigComp code sent between compressor and decompressor. Since the gain of having SigComp code compressed should be minimal in most cases, it is NOT RECOMMENDED to use TLS compression when SigComp compression is being used.
しかし、この方法で二回メッセージを圧縮することは一般的に大きな利益をもたらすものではありません。メッセージのSigCompを使用して圧縮されると、TLSは、通常、さらに、それを圧縮することができません。したがって、TLSは通常のみ、コンプレッサとデコンプレッサとの間で送信されるのSigCompコードを圧縮することができるであろう。 SigCompのコードが圧縮さを有するの利得はほとんどの場合、最小でなければならないので、のSigComp圧縮が使用されている場合TLS圧縮を使用することが推奨されていません。
Figure 1 shows an example message flow where the user agent and the outbound proxy exchange compressed SIP traffic. Compressed messages are marked with a (c).
図1は、ユーザエージェントとアウトバウンドプロキシ交換がSIPトラフィックを圧縮例示的メッセージフローを示します。圧縮されたメッセージは、（C）が付いています。
User Agent Outbound Proxy Registrar
ユーザエージェントアウトバウンドプロキシレジストラ
|(1) REGISTER (c) | |
|---------------->| |
| |(2) REGISTER |
| |---------------->|
| |(3) 200 OK |
| |<----------------|
|(4) 200 OK (c) | |
|<----------------| |
|(5) INVITE (c) | |
|---------------->| |
| |(6) INVITE |
| |------------------------------>
| |(7) 200 OK |
| |<------------------------------
|(8) 200 OK (c) | |
|<----------------| |
|(9) ACK (c) | |
|---------------->| |
| |(10) ACK |
| |------------------------------>
|(11) BYE (c) | |
|---------------->| |
| |(12) BYE |
| |------------------------------>
| |(13) 200 OK |
| |<------------------------------
|(14) 200 OK (c) | |
|<----------------| |
Figure 1: Example Message Flow
図1：例メッセージフロー
The user agent in Figure 1 is initially configured (e.g., using the SIP configuration framework [CONFIG]) with the URI of its outbound proxy. That URI contains the outbound proxy's SIP/SigComp identifier, referred to as 'Outbound-id', in a 'sigcomp-id' parameter.
図1のユーザエージェントは、最初に（例えば、SIPコンフィギュレーションフレームワーク[CONFIG]を使用して）そのアウトバウンドプロキシのURIとが構成されています。 URIがアウトバウンドプロキシのSIP / SigCompの識別子が含まれていることを、「のSigComp-ID」パラメータで、「アウトバウンド-ID」と呼びます。
When the user agent sends an initial REGISTER request (1) to the outbound proxy's URI, the user agent opens a new compartment for 'Outbound-id'. This compartment will be valid for the duration of the registration, at least.
ユーザエージェントは、アウトバウンドプロキシのURIへの初期のREGISTERリクエスト（1）を送信すると、ユーザーエージェントは、「アウトバウンド-ID」のための新しいコンパートメントを開きます。このコンパートメントは、少なくとも、登録の期間中に有効になります。
On receiving this REGISTER request (1), the outbound proxy opens a new compartment for the SIP/SigComp identifier that appears in the 'sigcomp-id' parameter of the top-most Via entry. This identifier, which is the user agent's SIP/SigComp identifier, is referred to as 'UA-id'. The compartment opened by the outbound proxy will be valid for the duration of the registration, at least. The outbound proxy adds a Path header field with its own URI, which contains the 'Outbound-id' SIP/SigComp identifier, to the REGISTER request and relays it to the registrar (2).
このREGISTERリクエスト（1）を受信すると、アウトバウンドプロキシは、最上位のViaエントリの「SigCompの-ID」パラメータに表示されますSIP / SigCompの識別子のための新しいコンパートメントを開きます。ユーザエージェントのSIP / SigCompの識別子であり、この識別子は、「UA-ID」と呼ばれます。アウトバウンドプロキシによって開かれたコンパートメントは、少なくとも、登録の期間中に有効になります。アウトバウンドプロキシは、REGISTER要求およびレジストラ（2）への中継をする「アウトバウンド-ID」SIP / SigCompの識別子を含み、それ自身のURIとパスヘッダフィールドを付加します。
When the registrar receives the REGISTER request (2), it constructs the route future incoming requests (to the user agent) will follow using the Contact and the Path header fields. Future incoming requests will traverse the outbound proxy before reaching the user agent.
レジストラは、登録要求を受信した場合（2）は、（ユーザエージェント）がルート将来着信要求を構築連絡先とPathヘッダフィールドを使用して続きます。今後の着信要求は、ユーザーエージェントに到達する前に、アウトバウンドプロキシを通過します。
The registrar also constructs the route future outgoing requests (from the user agent) will follow and places it in a Service-Route header field in a 200 (OK) response (3). Future outgoing requests will always traverse the outbound proxy. The registrar has ensured that the outbound proxy performing compression handles both incoming and outgoing requests.
レジストラはまた、200（OK）応答サービス-Routeヘッダフィールドにルート将来発信（ユーザエージェントからの）要求続くや場所を構築する（3）。今後の発信要求は常にアウトバウンドプロキシを通過します。レジストラは、圧縮を行うアウトバウンドプロキシの両方の着信および発信要求を処理することを保証しています。
When the outbound proxy receives a 200 (OK) response (3), it inspects the top-most Via entry. This entry's SIP/SigComp identifier 'UA-id' matches that of the compartment created before. Therefore, the outbound proxy uses that compartment to compress it and relay it to the user agent.
アウトバウンドプロキシは200（OK）応答（3）を受信すると、一番上の経由エントリを検査します。このエントリのSIP / SigCompの識別子「UA-ID」は以前に作成されたコンパートメントのそれと一致しました。したがって、アウトバウンドプロキシは、それを圧縮してユーザーエージェントに中継するために、その区画を使用します。
On receiving the 200 (OK) response (4), the user agent stores the Service-Route header field in order to use it to send future outgoing requests. The Service-Route header field contains the outbound proxy's URI, which contains the 'Outbound-id' SIP/SigComp identifier.
200（OK）レスポンス（4）を受信すると、ユーザエージェントは、将来の送信要求を送信するためにそれを使用するためにサービス-Routeヘッダフィールドを格納します。サービスルートヘッダフィールドは「アウトバウンド-ID」SIP / SigCompの識別子を含むアウトバウンドプロキシのURIを含んでいます。
At a later point, the user agent needs to send an INVITE request (5). According to the Service-Route header field received previously, the user agent sends the INVITE request (5) to the outbound proxy's URI.
後の時点で、ユーザエージェントは、INVITEリクエスト（5）を送信する必要があります。フィールドは、以前に受信したサービスルートヘッダによれば、ユーザエージェントは、アウトバウンドプロキシのURIに対してINVITE要求（5）を送信します。
Since this URI's SIP/SigComp identifier 'Outbound-id' matches that of the compartment created before, this compartment is used to compress the INVITE request.
このURIのSIP / SigCompの識別子「アウトバウンド-ID」は前に作成された区画で、この区画は、INVITEリクエストを圧縮するために使用されていることと一致します。
On receiving the INVITE request (5), the outbound proxy Record Routes and relays the INVITE request (6) forward. The outbound proxy Record Routes to ensure that all SIP messages related to this new dialog are routed through the outbound proxy.
INVITEリクエスト（5）、アウトバウンドプロキシレコードルートを受信すると、INVITE要求を中継する（6）フォワード。この新しいダイアログに関連するすべてのSIPメッセージは、アウトバウンドプロキシを介してルーティングされることを保証するアウトバウンドプロキシレコードルート。
Finally, the dialog is terminated by a BYE transaction (11) that also traverses the outbound proxy.
最後に、ダイアログはまた、アウトバウンドプロキシを横断BYEトランザクション（11）で終了します。
The same security considerations as described in [RFC3320] apply to this document. Note that keeping SigComp states longer than the duration of a SIP dialog should not pose new security risks because the state has been allowed to be created in the first place.
[RFC3320]で説明したのと同じセキュリティ上の考慮事項は、この文書に適用されます。状態が最初の場所で作成することを許可されているためにSigCompが長いSIPダイアログの持続時間よりも述べて維持することは、新たなセキュリティ上のリスクをもたらすべきではないことに注意してください。
The IANA has registered the 'sigcomp-id' Via header field parameter, which is defined in Section 9.1, under the Header Field Parameters and Parameter Values subregistry within the SIP Parameters registry:
IANAは、ヘッダーフィールドパラメータの下で、セクション9.1で定義されたヘッダフィールドパラメータを介して、「のSigComp-ID」を登録しており、パラメータは、SIPパラメータレジストリ内の副登録値：
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Via sigcomp-id No [RFC5049]
The IANA has registered the 'sigcomp-id' SIP URI parameter, which is defined in Section 9.1, under the SIP/SIPS URI Parameters subregistry within the SIP Parameters registry:
IANAは、SIPの下で、セクション9.1で定義されている「のSigComp-ID」SIP URIパラメータを、登録している/ SIPパラメータレジストリ内のURIパラメータ副登録をSIPS。
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
sigcomp-id No [RFC5049]
The authors would like to thank the following people for their comments and suggestions: Jan Christoffersson, Joerg Ott, Mark West, Pekka Pessi, Robert Sugar, Jonathan Rosenberg, Robert Sparks, Juergen Schoenwaelder, and Tuukka Karvonen. Abigail Surtees and Adam Roach performed thorough reviews of this document.
ヤンChristoffersson、イェルク・オット、マーク・西、ペッカPessi、ロバート・シュガー、ジョナサン・ローゼンバーグ、ロバート・スパークス、ユルゲンSchoenwaelder、およびTuukkaカルボーネン：作者は彼らのコメントと提案については、以下の人々に感謝したいと思います。アビゲイルサーティースとアダムローチは、このドキュメントの徹底的なレビューを行いました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141]堀、R.、 "URN構文"、RFC 2141、1997年5月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension", RFC 3308, November 2002.
[RFC3308]カルフーン、P.、羅、W.、マクファーソン、D.、およびK.パース、 "レイヤ2トンネリングプロトコル（L2TP）差別化サービス拡張"、RFC 3308、2002年11月。
[RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[RFC3320]価格、R.、ボルマン、C.、Christoffersson、J.、ハンヌ、H.、劉、Z.、およびJ.ローゼンバーグ、 "シグナリング圧縮（SigCompの）"、RFC 3320、2003年1月。
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[RFC3327]ウィリス、D.とB. Hoeneisen、 "セッション開始プロトコル非隣接コンタクトを登録するための（SIP）拡張ヘッダーフィールド"、RFC 3327、2002年12月。
[RFC3485] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and A. Roach, "The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)", RFC 3485, February 2003.
[RFC3485]ガルシア - マーチン、M.、ボルマン、C.、オット、J.、価格、R.、およびA.ローチ、「シグナリング圧縮のためのセッション開始プロトコル（SIP）およびセッション記述プロトコル（SDP）静的辞書（のSigComp）」、RFC 3485、2003年2月。
[RFC3486] Camarillo, G., "Compressing the Session Initiation Protocol (SIP)", RFC 3486, February 2003.
[RFC3486]キャマリロ、G.、RFC 3486 "セッション開始プロトコルを（SIP）圧縮"、2003年2月。
[RFC4077] Roach, A., "A Negative Acknowledgement Mechanism for Signaling Compression", RFC 4077, May 2005.
[RFC4077]ローチ、A.、 "シグナリング圧縮のための否定応答メカニズム"、RFC 4077、2005年5月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122]リーチ、P.、Mealling、M.、およびR. Salzの、 "汎用一意識別子（UUID）URN名前空間"、RFC 4122、2005年7月。
[RFC4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
"構文仕様のための増大しているBNF：ABNF" [RFC4234]クロッカー、D.、エド、およびP. Overell、。、RFC 4234、2005年10月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[RFC4896] Surtees, A., West, M., and A. Roach, "Signaling Compression (SigComp) Corrections and Clarifications", RFC 4896, June 2007.
[RFC4896]サーティース、A.、西、M.、およびA.ローチ、 "シグナリング圧縮（SigCompの）訂正と明確化"、RFC 4896、2007年6月。
[CONFIG] Petrie, D. and S. Channabasappa, "A Framework for Session Initiation Protocol User Agent Profile Delivery", Work in Progress, June 2007.
[CONFIG]ペトリー、D.とS. Channabasappa、「セッション開始プロトコルユーザエージェントプロファイル配信のためのフレームワーク」が進歩、2007年6月に作業。
[OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, March 2007.
[OUTBOUND]ジェニングス、C.とR.マーイ、進歩、2007年3月に仕事「セッション開始プロトコル（SIP）でのクライアント開始された接続の管理」を参照してください。
Authors' Addresses
著者のアドレス
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28334 Germany
カルステンボルマンUniversitaetブレーメンTZI POSTFACH 330440 D-28334ブレーメンドイツ
Phone: +49 421 218 63921 Fax: +49 421 218 7000 EMail: cabo@tzi.org
電話：+49 421 218 63921ファックス：+49 421 218 7000 Eメール：cabo@tzi.org
Zhigang Liu Nokia Research Center 955 Page Mill Road Palo Alto, CA 94304 USA
劉志剛ノキア・リサーチセンター955ページミルロードパロアルト、CA 94304 USA
Phone: +1 650 796 4578 EMail: zhigang.c.liu@nokia.com
電話：+1 650 796 4578 Eメール：zhigang.c.liu@nokia.com
Richard Price EADS Defence and Security Systems Limited Meadows Road Queensway Meadows Newport, Gwent NP19 4SS
リチャード価格EADSの防衛およびセキュリティ・システムズ・リミテッドメドウズ道路クイーンズウェイメドウズニューポート、グウェントNP19 4SS
Phone: +44 (0)1633 637874 EMail: richard.price@eads.com
電話：+44（0）1633 637874 Eメール：richard.price@eads.com
Gonzalo Camarillo (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロ（エディタ）エリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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, THE IETF TRUST 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が表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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に情報を記述してください。