[要約] RFC 5049は、SIPにSigCompを適用する方法について説明しています。SigCompは、SIPメッセージの圧縮を実現し、ネットワークの帯域幅を節約することを目的としています。
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)
セッション開始プロトコル（SIP）にシグナリング圧縮（SIGCOMP）を適用する
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パラメーターのデフォルト最小値、コンパートメント、状態管理、および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]と同様に、このドキュメントに適合する必要があります。さらに、[RFC3485]で指定されているSIP/SDP静的辞書と、[RFC3486]で指定されているSIP層でSIGCOMPサポートを発見するメカニズムをサポートする必要があります。
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はSigCompの動作を記述するためのいくつかのパラメーターを定義します（[RFC3320]のセクション3.3を参照）。各パラメーターについて、[RFC3320]は、SIGCOMPエンドポイントが任意の/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の場合は増加します。完全性のために、SIP/Sigcompと同じ/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].
[RFC3320]のセクション3.3.1で指定されているように、任意の/sigcompの最小値：2048バイト。
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]によって設定された条件は次のとおりです。したがって、DMSが小さすぎる場合、C、B、R、またはSの少なくとも1つは厳しく制限されます。一方、DMSは、SigCompメッセージの減圧中に一時的に必要なメモリです（メッセージが減圧されたときにメモリを取り戻すことができます）。したがって、8 KBの要件は、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
cバイトコードのr bサイズに応じて、圧縮アプリケーションメッセージのサイズ。注：2つのコピー - 1つはSigCompメッセージの一部として、もう1つはUDVM（Universal Decompressor Virtual Machine）メモリにあります。r udvmメモリの円形バッファーのサイズs減圧の終わりに円形バッファーの内容から作成されたもの以外にアップロードされた追加の状態（bと同様、Sの2つのコピーが必要です）128コピーするUDVMメモリの最小のアドレスbytecode to
Minimum value for ANY/SigComp: 0 (zero) bytes, as specified in Section 3.3.1 of [RFC3320].
[RFC3320]のセクション3.3.1で指定されているように、任意の/sigcomp：0（ゼロ）バイトの最小値。
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 SigComp function. Stateful implementations should have little problem to keep 2K additional state for each compartment (see Section 9).
理由：ゼロ以外のSMSにより、エンドポイントは、リモートエンドポイントにそのような状態を保存するのに十分なメモリがあるかどうかの不確実性なしに、リモートエンドポイントに送信された最初のSIPメッセージに状態をアップロードできます。ゼロ以外のSMSは、明らかに状態を維持するためにSIP/SIGCOMPの実装を必要とします。ステートレスSigcomp圧縮からの利益がほとんどないという観察に基づいて、純粋に無国籍のSIP実装が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で指定されている/sigcomp：16の最小値：16。
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].
任意の/sigcomp：0x01、[RFC3320]のセクション3.3.2で指定されています。
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メッセージが発信されるコンプレッサーに送信されます。また、コンプレッサーは[RFC4077]のセクション2.4（NACKのサポートを検出）で詳述されている方法を使用する必要がないことを意味します。たとえば、最初から楽観的な圧縮方法を使用できます。
Minimum LAS for ANY/SigComp: none, see Section 3.3.3 of [RFC3320].
/sigcompの最小LA：なし、[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.
UDPやStream Control Transmission Protocol（SCTP）などのメッセージベースのトランスポートの場合、メッセージごとにSigCompと非SigCompメッセージを区別できます。受信エンドポイントは、UDP/SCTPペイロードの最初のオクテットをチェックして、SigCompを使用してメッセージが圧縮されているかどうかを判断します。OctetのMSB（最も重要なビット）が「11111」の場合、メッセージはSigCompメッセージと見なされ、[RFC3320]に従って解析されます。OctetのMSBが他の値を取得した場合、メッセージは圧縮されていない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.
TCPなどのストリームベースのトランスポートの場合、SigCompと非SigCompメッセージを区別する必要があります。接続ごとに実行する必要があります。受信エンドポイントは、TCPデータストリームの最初のオクテットをチェックして、SigCompを使用してストリームが圧縮されているかどうかを判断します。オクテットのMSBが「11111」の場合、ストリームはSigCompメッセージを含むと見なされ、[RFC3320]に従って解析されます。OctetのMSBが他の値を取得する場合、ストリームは圧縮されていない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メッセージと非圧縮されていない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を超えるメッセージの圧縮をサポートしていません。したがって、SIPアプリケーションが圧縮されたSIPメッセージをトランスポート接続を介して別のSIPアプリケーションに送信する場合（たとえば、TCP接続）、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の再送信は、元のメッセージまたはその応答が減圧の障害によって失われたことによって引き起こされる可能性があることに注意してください。この場合、decompressorからコンプレッサーに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]は、時間、一意の名前（メディアアクセスコントロール（MAC）アドレスなど）、または乱数ジェネレーターに基づいて、URNの非中央集権化された計算を可能にします。UUID以外のURNスキームを使用する場合、他のSIP/SIGCOMPアプリケーションが同じURN値を選択しないことをアプリケーションが確実にすることができるように、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識別子の定義は、[アウトバウンド]のインスタンス識別子の定義に似ていることに注意してください。1つの違いは、インスタンス識別子はAOR内でのみ一意である必要があること（記録のアドレス）であることですが、SIP/SIGCOMP識別子はグローバルに一意であることが必要です。
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識別子に同じ値を使用すると、両方の識別子を運ぶヘッダーフィールドの圧縮比が改善されます（例：レジスタリクエストの連絡先ヘッダーフィールド）。
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（ユニフォームリソース識別子）またはヘッダーフィールドパラメーターを介して運ばれます。'Sigcomp-id' SIP URIパラメーターは、SIP ABNF（[RFC3261]のセクション25.1）で定義されているように、「uri-parameter」です。以下はABNF [RFC4234]です。
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]:
via 'sigcomp-id'パラメーターは、sip abnf（[rfc3261]のセクション25.1）で定義されているように、「エクステンション」です。以下はABNF [RFC4234]です。
via-sip-sigcomp-id = "sigcomp-id" EQUAL LDQUOT *( qdtext / quoted-pair ) RDQUOT
via-sip-sigcomp-id = "sigcomp-id" equal ldquot *（qdtext / quoted-pair）rdquot
The Via 'sigcomp-id' parameter MUST contain a URN [RFC2141].
via '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
The following is an example of a Via header field with a 'sigcomp-id' parameter:
以下は、「sigcomp-id」パラメーターを備えたヘッダーフィールドの例です。
Via: SIP/2.0/UDP server1.example.com:5060
;branch=z9hG4bK87a7
;comp=sigcomp
;sigcomp-id="urn: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.
以下は、viaエントリおよびコンタクトヘッダーフィールドに「Sigcomp-id」パラメーターを掲載するレジスタリクエストの例です。さらに、「sip.instance」コンタクトヘッダーフィールドパラメーターも搭載されています。
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識別子が含まれていない場合、リモートアプリケーション識別子は、接続のない輸送プロトコルのリクエストを運ぶデータグラムのIPアドレスとポートのポートであり、接続の要求を伝えるトランスポート接続（TCP接続など） - 指向輸送プロトコル（これは、レガシー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識別子が含まれていない場合、リモートアプリケーション識別子はソースIPアドレスと、接続のない輸送プロトコルのリクエストを運ぶデータグラムのポートと、リクエストを運ぶトランスポート接続（たとえば、TCP接続）です。接続指向のトランスポートプロトコルの場合（これは、レガシー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」パラメーターを含むエントリ経由で独自の生成する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スキームを理解していない場合、RFC 2141 [RFC2141]で定義された語彙等式ルールを使用して比較を実行します。語彙の平等は、2つのurが実際に等しい場合、不平等であると見なされる可能性があります。urnsのこの特定の使用法では、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コンパートメントの寿命を登録状態にリンクすると、この仕様の適用性が制限されます。特に、登録していないが、たとえば公開または購読/通知のみを処理するSIPユーザーエージェントは、この仕様に従ってSIP/SIGCOMPコンパートメントを作成できません。この仕様の以前の改訂は、SIPトランザクションまたはSIPダイアログ中に有効なコンパートメントも定義しました。これらのコンパートメントは、登録トランザクションを処理しないものを含むすべての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 Acknowledgement (NACK) Mechanism [RFC4077] in SIP/SigComp ensures that it is possible to recover from synchronization errors regarding compartment lifetimes.
Sigcompのエンドポイントは、コンパートメントのデフォルトの寿命を超えて、SigCompピアエンドポイントからの要求に応じて作成された状態を保持することを提案する場合があります（つまり、関連する登録の期間を超えて）。これは、Sigcomp Peerエンドポイントで同じリモートアプリケーションによって生成された後続のSIPメッセージの圧縮効率を改善するために使用できます。そのような状態が引き続き利用可能であることを示すために、Sigcompのエンドポイントは、Sigcomp状態の寿命を制限することになっている登録の終了時に、返されたSigcompパラメーターで（部分的な）状態IDを発表することにより、ピアSigCompエンドポイントに通知することができます。。状態が維持されることを示します。SIP/SIGCOMPの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 Negative Ancoundage（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.
登録トランザクションにより、アプリケーションが登録トランザクションによって確立された登録期間中、新しいコンパートメントを開くことになります。
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レジスタ（つまり、レジスタを生成するユーザーエージェントまたは次のホップにリレーするプロキシサーバー）を送信する必要があるSIPアプリケーションは、リクエストのリモートアプリケーション識別子のコンパートメントを開く必要があります。圧縮されたSIPレジスタ（つまり、レジストラまたはレジスタを次のホップに中継するプロキシ）を受信するSIPアプリケーションは、リクエストのリモートアプリケーション識別子のコンパートメントを開く必要があります。
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.
これらのコンパートメントは、レジスタリクエストが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ネットワークは、ユーザーエージェントとの間の定期的なSIPトラフィックが、最初のレジスタトランザクションとは異なるプロキシセットを横断するように構成できます。レジスタトランザクションが次のパスは、通常、構成データによって決定されます。パス後続のリクエストトラバースは、レジスタトランザクションのパス[RFC3327]およびサービスルート[RFC3308]ヘッダーフィールドと、ダイアログ作成トランザクションのレコードルートとルートヘッダーフィールドによって決定されます。このドキュメントの以前の改訂は、さまざまな種類のトラフィックに対する異なるパスの使用をサポートしました。ただし、単純な理由で、このドキュメントは、圧縮を使用したネットワークが設定され、その後のリクエストが可能な限り最高の圧縮を実現するために初期レジスタトランザクションと同じパスに従うように設定されることを想定しています。セクション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アプリケーションは、登録と同じEdgeプロキシサーバーを使用して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".
「next-Hop 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.
以前に説明したルートは、ダイアログの外部で送信されたリクエストに適用されます。ダイアログ内のリクエストは、レコードルートヘッダーフィールドを使用して構築されたルートに従います。ダイアログ外のリクエストのルートにあるSigCompを実行するプロキシは、ダイアログ内のリクエストに使用されるルートに（レコードルートヘッダーフィールドに自分自身を挿入することによって）自分自身を配置するように構成されることをお勧めします。
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）。o連続モードの使用（セクション6）。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によって提供される圧縮を使用できます。SIP/ SIGCOMPトラフィックをTLS接続で交換する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.
ただし、この方法でメッセージを2回圧縮しても、通常、大きな利益はもたらされません。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には、「Sigcomp-ID」パラメーターに「アウトバウンドID」と呼ばれるアウトバウンドプロキシのSIP/SIGCOMP識別子が含まれています。
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.
ユーザーエージェントが最初のレジスタリクエスト（1）をアウトバウンドプロキシのURIに送信すると、ユーザーエージェントは「アウトバウンド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).
このレジスタリクエスト（1）を受信すると、アウトバウンドプロキシは、エントリを介して最上位の「SIGCOMP-ID」パラメーターに表示されるSIP/SIGCOMP識別子の新しいコンパートメントを開きます。ユーザーエージェントのSIP/SIGCOMP識別子であるこの識別子は、「UA-ID」と呼ばれます。アウトバウンドプロキシによって開かれたコンパートメントは、少なくとも登録期間中に有効です。アウトバウンドプロキシは、「アウトバウンドID」SIP/SIGCOMP識別子を含む独自のURIを備えたパスヘッダーフィールドをレジスタリクエストに追加し、レジストラにリレーします（2）。
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）を受信すると、（ユーザーエージェントへの）将来の着信要求を構築します。連絡先とパスヘッダーフィールドを使用します。将来の着信リクエストは、ユーザーエージェントに到達する前に、アウトバウンドプロキシを横断します。
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）応答（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）を受信すると、ユーザーエージェントはサービスルートヘッダーフィールドを保存して、将来の発信リクエストを送信するために使用します。Service-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.
後の時点で、ユーザーエージェントは招待リクエストを送信する必要があります（5）。以前に受け取ったサービスルートヘッダーフィールドによると、ユーザーエージェントは招待リクエスト（5）をアウトバウンドプロキシのURIに送信します。
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識別子「Outbound-ID」は、以前に作成されたコンパートメントのものと一致するため、このコンパートメントは招待リクエストを圧縮するために使用されます。
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.
招待リクエスト（5）を受信すると、アウトバウンドプロキシレコードがルートルーティングし、招待リクエスト（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は、ヘッダーフィールドパラメーターを介して「SigComp-ID」を登録しました。これは、SIPパラメータレジストリ内のヘッダーフィールドパラメーターとパラメーター値サブレジストリの下で、セクション9.1で定義されています。
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/SIPS URIパラメータサブレジストリの下で、セクション9.1に定義されている「SigComp-ID」SIP URIパラメーターを登録しました。
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.
著者は、Jan Christoffersson、Joerg Ott、Mark West、Pekka Pessi、Robert Sugar、Jonathan Rosenberg、Robert Sparks、Juergen Schoenwaelder、Tuukka Karvonenのコメントと提案について、次の人々にコメントと提案に感謝したいと思います。Abigail SurteesとAdam Roachは、この文書の徹底的なレビューを行いました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141] Moats、R。、「Urn Syntax」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、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] Calhoun、P.、Luo、W.、McPherson、D。、およびK. Peirce、「レイヤー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] Price、R.、Bormann、C.、Christoffersson、J.、Hannu、H.、Liu、Z。、およびJ. Rosenberg、「シグナリング圧縮（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] Willis、D。およびB. Hoeneisen、「Addjacentコンタクトを登録するためのセッション開始プロトコル（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] Garcia-Martin、M.、Bormann、C.、Ott、J.、Price、R。、およびA. Roach、「セッション開始プロトコル（SIP）およびセッション説明プロトコル（SDP）静的辞書のシグナリング圧縮のための静的辞書（Sigcomp） "、RFC 3485、2003年2月。
[RFC3486] Camarillo, G., "Compressing the Session Initiation Protocol (SIP)", RFC 3486, February 2003.
[RFC3486] Camarillo、G。、「セッション開始プロトコル（SIP）の圧縮」、RFC 3486、2003年2月。
[RFC4077] Roach, A., "A Negative Acknowledgement Mechanism for Signaling Compression", RFC 4077, May 2005.
[RFC4077] Roach、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] Leach、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.
[RFC4234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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] Surtees、A.、West、M。、およびA. Roach、「シグナリング圧縮（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] Petrie、D。and 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.
[Autbound] Jennings、C。and R. Mahy、「クライアントのマネージングクライアントは、セッション開始プロトコル（SIP）で接続を開始しました」、2007年3月、進行中の作業。
Authors' Addresses
著者のアドレス
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28334 Germany
Carsten Bormann Universitaet Bremen Tzi Postfach 330440 Bremen D-28334ドイツ
Phone: +49 421 218 63921
Fax: +49 421 218 7000
EMail: cabo@tzi.org
Zhigang Liu Nokia Research Center 955 Page Mill Road Palo Alto, CA 94304 USA
Zhigang Liu Nokia Research Center 955 Page Mill Road Palo Alto、CA 94304 USA
Phone: +1 650 796 4578
EMail: zhigang.c.liu@nokia.com
Richard Price EADS Defence and Security Systems Limited Meadows Road Queensway Meadows Newport, Gwent NP19 4SS
リチャード・プライスEADS防衛およびセキュリティシステムリミテッドメドウズロードクイーンズウェイメドウズニューポート、GWENT NP19 4SS
Phone: +44 (0)1633 637874
EMail: richard.price@eads.com
Gonzalo Camarillo (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンザロカマリロ（編集者）エリクソンハーサランティ11ジョルバス02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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への情報をお問い合わせください。