[要約] RFC 3486は、SIPの圧縮に関する標準化文書であり、SIPメッセージのサイズを縮小するための手法を提供します。目的は、ネットワークの帯域幅を節約し、通信の効率を向上させることです。
Network Working Group G. Camarillo
Request for Comments: 3486 Ericsson
Category: Standards Track February 2003
Compressing the Session Initiation Protocol (SIP)
セッション開始プロトコルの圧縮（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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity.
このドキュメントは、1つ以上のセッション開始プロトコル（SIP）メッセージに対して圧縮が望ましいことを示すメカニズムについて説明しています。また、圧縮されたSIPメッセージをSIPエンティティに送信することが適切な場合にも述べられています。
Table of Contents
目次
1. Introduction ............................................... 2
2. Overview of operation ...................................... 3
3. SigComp implementations for SIP ............................ 3
4. Sending a Request to a Server .............................. 3
4.1 Obtaining a SIP or SIPS URI with comp=sigcomp ........ 4
5. Sending a Response to a Client ............................. 5
6. Double Record-Routing ...................................... 6
7. Error Situations ........................................... 6
8. Augmented BNF .............................................. 7
9. Example .................................................... 7
10. Security Considerations .................................... 10
11. IANA Considerations ........................................ 10
12. Acknowledgements............................................ 10
13. Normative References ....................................... 10
14. Informative References ..................................... 11
15. Author's Address............................................ 11
16. Full Copyright Statement.................................... 12
A SIP [1] client sending a request to a SIP server typically performs a DNS lookup for the domain name of the server. When NAPTR [4] or SRV [5] records are available for the server, the client can specify the type of service it wants. The service in this context is the transport protocol to be used by SIP (e.g., UDP, TCP or SCTP). A SIP server that supports, for instance, three different transport protocols, will have three different DNS entries.
SIP [1]クライアントがSIPサーバーにリクエストを送信するクライアントは、通常、サーバーのドメイン名のDNSルックアップを実行します。サーバーでNAPTR [4]またはSRV [5]レコードが利用可能な場合、クライアントは必要なサービスのタイプを指定できます。このコンテキストでのサービスは、SIP（UDP、TCP、またはSCTPなど）で使用されるトランスポートプロトコルです。たとえば、3つの異なるトランスポートプロトコルをサポートするSIPサーバーには、3つの異なるDNSエントリがあります。
Since it is foreseen that the number of transport protocols supported by a particular application layer protocol is not going to grow dramatically, having a DNS entry per transport seems like a scalable enough solution.
特定のアプリケーションレイヤープロトコルによってサポートされる輸送プロトコルの数が劇的に成長しないことが予見されているため、輸送ごとにDNSエントリを持つことは十分な十分なソリューションのように思える。
However, sometimes it is necessary to include new layers between the transport protocol and the application layer protocol. Examples of these layers are transport layer security and compression. If DNS was used to discover the availability of these layers for a particular server, the number of DNS entries needed for that server would grow dramatically.
ただし、輸送プロトコルとアプリケーションレイヤープロトコルの間に新しいレイヤーを含める必要がある場合があります。これらのレイヤーの例は、輸送層のセキュリティと圧縮です。DNSを使用して特定のサーバーのこれらのレイヤーの可用性を発見した場合、そのサーバーに必要なDNSエントリの数は劇的に増加します。
A server that, for example, supported TCP and SCTP as transports, TLS for transport security and SigComp for signaling compression, would need the 8 DNS entries listed below:
たとえば、TCPとSCTPを輸送としてサポートするサーバー、輸送セキュリティのTLS、信号圧縮のSIGCOMPには、以下にリストされている8つのDNSエントリが必要です。
1. TCP, no security, no compression
1. TCP、セキュリティなし、圧縮なし
2. TCP, no security, SigComp
2. TCP、セキュリティなし、sigcomp
3. TCP, TLS, no compression
3. TCP、TLS、圧縮なし
4. TCP, TLS, SigComp
4. TCP、TLS、Sigcomp
5. SCTP, no security, no compression
5. SCTP、セキュリティなし、圧縮なし
6. SCTP, no security, SigComp
6. SCTP、セキュリティなし、sigcomp
7. SCTP, TLS, no compression
7. SCTP、TLS、圧縮なし
8. SCTP, TLS, SigComp
8. SCTP、TLS、Sigcomp
It is clear that this way of using DNS is not scalable. Therefore, an application layer mechanism to express support of signalling compression is needed.
DNSを使用するこの方法がスケーラブルではないことは明らかです。したがって、シグナル伝達圧縮のサポートを表現するためのアプリケーション層メカニズムが必要です。
Note that for historical reasons both HTTP and SIP use a different port for TLS on top of TCP than for TCP alone, although at present, this solution is not considered scalable any longer.
歴史的な理由で、HTTPとSIPの両方がTCPのみよりもTCPの上にあるTLSに対して異なるポートを使用していることに注意してください。ただし、現在、このソリューションはもはやスケーラブルではないとは見なされません。
A SIP element that supports compression will need to be prepared to receive compressed and uncompressed messages on the same port. It will perform demultiplexing based on the cookie in the topmost bits of every compressed message.
圧縮をサポートするSIP要素は、同じポートで圧縮されていないメッセージを受信するために準備する必要があります。すべての圧縮メッセージの一番上のビットにあるCookieに基づいて、脱grexを実行します。
There are two types of SIP messages; SIP requests and SIP responses. Clients send SIP requests to the host part of a URI and servers send responses to the host in the sent-by parameter of the Via header field.
SIPメッセージには2つのタイプがあります。SIPリクエストとSIP応答。クライアントはURIのホスト部分にSIPリクエストを送信し、サーバーは、Viaヘッダーフィールドのセントバパラメーターでホストに応答を送信します。
We define two parameters, one for SIP URIs and the other for the Via header field. The format of both parameters is the same, as shown in the examples below:
2つのパラメーターを定義します。1つはSIP URI用、もう1つはViaヘッダーフィールド用です。両方のパラメーターの形式は、以下の例に示すように同じです。
sip:alice@atlanta.com;comp=sigcomp
Via: SIP/2.0/UDP server1.foo.com:5060;branch=z9hG4bK87a7;comp=sigcomp
The presence of this parameter (comp=sigcomp) in a URI indicates that the request has to be compressed using SigComp, as defined in [2]. The presence of comp=sigcomp in a Via header field indicates that the response has to be compressed using SigComp.
URIにおけるこのパラメーター（comp = sigcomp）の存在は、[2]で定義されているように、sigcompを使用してリクエストを圧縮する必要があることを示しています。viaヘッダーフィールドにcomp = sigcompの存在は、Sigcompを使用して応答を圧縮する必要があることを示しています。
Therefore, the presence of comp=sigcomp indicates that the SIP entity identified by the URI or by the Via header field supports SigComp and is willing to receive compressed messages. Having comp=sigcomp mean "willingness" as well as "support" allows the receiver of a SIP message to influence the decision of whether or not to use SigComp at a given time.
したがって、comp = sigcompの存在は、URIまたはviaヘッダーフィールドによって識別されたSIPエンティティがSigcompをサポートし、圧縮メッセージを喜んで受信することを示しています。comp = sigcompは「意欲」と「サポート」を意味することで、SIPメッセージの受信者が特定の時間にSigCompを使用するかどうかの決定に影響を与えることができます。
Every SIP implementation that supports SigComp MUST implement the procedures described in this document.
SigCompをサポートするすべてのSIP実装は、このドキュメントで説明されている手順を実装する必要があります。
A request is sent to the host part of a URI. This URI, referred to as the next-hop URI, is the Request-URI of the request or an entry in the Route header field.
リクエストがURIのホスト部分に送信されます。次のホップURIと呼ばれるこのURIは、リクエストのリクエストまたはルートヘッダーフィールドのエントリです。
If the next-hop URI contains the parameter comp=sigcomp, the client SHOULD compress the request using SigComp as defined in [2].
Next-Hop URIにパラメーターcomp = sigcompが含まれている場合、クライアントは[2]で定義されているようにSigCompを使用して要求を圧縮する必要があります。
If the next-hop URI is a SIPS URI, the request SHOULD be compressed before it is passed to the TLS layer.
Next-Hop URIがSIPS URIの場合、TLSレイヤーに渡される前にリクエストを圧縮する必要があります。
A client MUST NOT send a compressed request to a server if it does not know whether or not the server supports SigComp.
サーバーがSigCompをサポートしているかどうかがわからない場合、クライアントはサーバーに圧縮要求を送信してはなりません。
Regardless of whether the request is sent compressed or not, if a client would like to receive subsequent requests within the same dialog in the UAS->UAC direction compressed, this client SHOULD add the parameter comp=sigcomp to the URI in the Contact header field if it is a user agent client. If the client is a proxy, it SHOULD add the parameter comp=sigcomp to its URI in the Record-Route header field.
リクエストが圧縮されるかどうかに関係なく、クライアントがUAS-> UAC方向の同じダイアログ内で後続のリクエストを受信したい場合、このクライアントはコンタクトヘッダーフィールドのパラメーターcomp = sigcompをURIに追加する必要がありますユーザーエージェントクライアントの場合。クライアントがプロキシである場合、パラメーターcomp = sigcompをRecord-routeヘッダーフィールドにURIに追加する必要があります。
If a user agent client sends a compressed request, it SHOULD add the parameter comp=sigcomp to the URI in the Contact header field. If a proxy that Record-Routes sends a compressed request, it SHOULD add comp=sigcomp to its URI in the Record-Route header field.
ユーザーエージェントクライアントが圧縮要求を送信する場合、コンタクトヘッダーフィールドのパラメーターcomp = sigcompをURIに追加する必要があります。レコードルートが圧縮リクエストを送信するプロキシの場合、レコードルートヘッダーフィールドのURIにcomp = sigcompを追加する必要があります。
If a client sends a compressed request, it SHOULD add the parameter comp=sigcomp to the topmost entry of the Via header field.
クライアントが圧縮要求を送信する場合、パラメーターcomp = sigcompをviaヘッダーフィールドの最上位エントリに追加する必要があります。
If a client does not know whether or not the server supports SigComp, but in case the server supported it, it would like to receive compressed responses, this client SHOULD add the parameter comp=sigcomp to the topmost entry of the Via header field. The request, however, as stated above, will not be compressed.
クライアントがサーバーがSIGCOMPをサポートしているかどうかを知らないが、サーバーがサポートしている場合、圧縮応答を受信したい場合、このクライアントはパラメーターcomp = sigcompをビアヘッダーフィールドの最上位エントリに追加する必要があります。ただし、上記のように、リクエストは圧縮されません。
For requests within a dialog, a next-hop URI with the comp=sigcomp parameter is obtained from a Record-Route header field when the dialog is established. A client sending a request outside a dialog can also obtain SIP URIs with comp=sigcomp in a Contact header field in a 3xx or 485 response to the request.
ダイアログ内のリクエストの場合、ダイアログが確立されたときに、comp = sigcompパラメーターを備えたネクストホップURIがレコードルートヘッダーフィールドから取得されます。ダイアログの外部でリクエストを送信するクライアントは、3xxまたは485のリクエストに対する485の応答でコンタクトヘッダーフィールドにcomp = sigcompを使用してSIP URIを取得することもできます。
However, clients establishing a session will not typically be willing to wait until the dialog is established in order to begin compressing messages. One of the biggest gains that SigComp can bring to SIP is the ability to compress the initial INVITE of a dialog, when the user is waiting for the session to be established. Therefore, clients need a means to obtain a comp=sigcomp URI from their outbound proxy before the user decides to establish a session.
ただし、セッションを確立するクライアントは、通常、メッセージの圧縮を開始するためにダイアログが確立されるまで待つことをいとわない。SigcompがSIPにもたらすことができる最大の利益の1つは、ユーザーがセッションの確立を待っているときに、ダイアログの最初の招待を圧縮する能力です。したがって、クライアントは、ユーザーがセッションを確立することを決定する前に、アウトバウンドプロキシからcomp = sigcomp uriを取得する手段を必要とします。
One solution to this problem is manual configuration. However, sometimes it is necessary to have clients configured in an automatic fashion. Unfortunately, current mechanisms for SIP client configuration (e.g., using DHCP [6]) do not allow to provide the client with URI parameters. In this case, the client SHOULD send an uncompressed OPTIONS request to its outbound proxy. The outbound proxy can provide an alternative SIP URI with the comp=sigcomp parameter in a Contact header field in a 200 OK response to the OPTIONS. The client can use this URI for subsequent requests that are sent through the same outbound proxy using compression.
この問題の解決策の1つは、手動構成です。ただし、クライアントを自動ファッションで構成する必要がある場合があります。残念ながら、SIPクライアント構成の現在のメカニズム（例：DHCP [6]を使用するなど）では、クライアントにURIパラメーターを提供することはできません。この場合、クライアントは、非圧縮オプションリクエストをアウトバウンドプロキシに送信する必要があります。アウトバウンドプロキシは、オプションに対する200 OK応答で、コンタクトヘッダーフィールドにcomp = sigcompパラメーターを備えた代替SIP URIを提供できます。クライアントは、このURIを使用して、圧縮を使用して同じアウトバウンドプロキシを介して送信される後続のリクエストに使用できます。
RFC 3261 [1] does not define how a proxy should respond to an OPTIONS request addressed to itself. It only describes how servers respond to OPTIONS addressed to a particular user. Section 11.2 of RFC 3261 says:
RFC 3261 [1]は、プロキシがそれ自体にアドレス指定されたオプション要求にどのように応答するかを定義していません。特定のユーザーにアドレス指定されたオプションにサーバーがどのように応答するかを説明するだけです。RFC 3261のセクション11.2は次のように述べています。
Contact header fields MAY be present in a 200 (OK) response and have the same semantics as in a 3xx response. That is, they may list a set of alternative names and methods of reaching the user.
コンタクトヘッダーフィールドは200（OK）応答で存在する場合があり、3XX応答と同じセマンティクスを持っています。つまり、ユーザーにリーチする代替名と方法のセットをリストする場合があります。
We extend this behavior to proxy servers responding to OPTIONS addressed to them. They MAY list a set of alternative URIs to contact the proxy.
この動作は、アドレス指定されたオプションに対応するプロキシサーバーに拡張します。代替URIのセットをリストして、プロキシに連絡する場合があります。
Note that receiving incoming requests (even initial INVITEs) compressed is not a problem, since user agents can REGISTER a SIP URI with comp=sigcomp in their registrar. All incoming requests for the user will be sent to this SIP URI using compression.
ユーザーエージェントがレジストラにcomp = sigcompを含むSIP URIを登録できるため、着信リクエスト（初期招待状）を受信することは問題ではありません。ユーザーのすべての着信リクエストは、圧縮を使用してこのSIP URIに送信されます。
A response is sent to the host in the sent-by parameter of the Via header field. If the topmost Via header field contains the parameter comp=sigcomp, the response SHOULD be compressed. Otherwise, the response MUST NOT be compressed.
ViaヘッダーフィールドのSent-byパラメーターのホストに応答が送信されます。最上部のヘッダーフィールドにパラメーターcomp = sigcompが含まれている場合、応答を圧縮する必要があります。それ以外の場合、応答を圧縮してはなりません。
In order to avoid asymmetric compression (i.e., two SIP entities exchanging compressed requests in one direction and uncompressed requests in the other direction) proxies need to rewrite their Record-Route entries in the responses. A proxy performing Record-Route inspects the Record-Route header field in the response and the Contact header field in the request that triggered this response (see example in Section 9). It looks for the URI of the next upstream (closer to the user agent client) hop in the route set. If this URI contains the parameter comp=sigcomp, the proxy SHOULD add comp=sigcomp to its entry in the Record-Route header field. If this URI does not contain the parameter comp=sigcomp, the proxy SHOULD remove comp=sigcomp (if it is present) from its entry in the Record-Route header field.
非対称の圧縮を避けるため（つまり、1つの方向に圧縮要求を交換する2つのSIPエンティティと他の方向の非圧縮要求）プロキシは、回答の記録的なエントリを書き直す必要があります。Record-routeを実行するプロキシは、この応答をトリガーしたリクエストで、応答のレコードルートヘッダーフィールドとコンタクトヘッダーフィールドを検査します（セクション9の例を参照）。ルートセットで次のアップストリーム（ユーザーエージェントクライアントに近い）ホップのURIを探します。このURIにパラメーターcomp = sigcompが含まれている場合、プロキシはcomp = sigcompをレコードルートヘッダーフィールドに追加する必要があります。このURIにパラメーターcomp = sigcompが含まれていない場合、プロキシはレコードルートヘッダーフィールドへのエントリからcomp = sigcomp（存在する場合）を削除する必要があります。
The same way, a user agent server SHOULD add comp=sigcomp to the Contact header field of the response if the URI of the next upstream hop in the route set contained the parameter comp=sigcomp.
同じように、ユーザーエージェントサーバーは、ルートセットの次のアップストリームホップのURIにパラメーターcomp = sigcompが含まれている場合、応答のコンタクトヘッダーフィールドにcomp = sigcompを追加する必要があります。
Although proxies usually add zero or one Record-Route entries to a particular request, some proxies add two of them to avoid Record-Route rewriting. A typical example of double Record-Routing is a SIP proxy that acts as a firewall between two networks. Depending on which network a request comes from, it will be received on a different interface by the proxy. The proxy adds one Record-Route entry for one interface and a second one for the other interface. This way, the proxy does not need to rewrite the Record-Route header field on the response.
プロキシは通常、特定のリクエストにゼロまたは1つのレコードルートエントリを追加しますが、記録的な書き換えを避けるために2つを追加します。ダブルレコードルーティングの典型的な例は、2つのネットワーク間のファイアウォールとして機能するSIPプロキシです。リクエストがどのネットワークから来るかに応じて、プロキシによって異なるインターフェイスで受信されます。プロキシは、1つのインターフェイスに1つのレコードルートエントリ、もう1つのインターフェイスに2番目のインターフェイスに追加されます。このようにして、プロキシは、応答に関するレコードルートヘッダーフィールドを書き換える必要はありません。
Proxies that receive compressed messages from one side of the dialog (e.g., upstream) and uncompressed messages from the other side (e.g., downstream) MAY use the mechanism described above.
ダイアログの片側から圧縮されたメッセージを受信するプロキシ（上流など）と反対側から非圧縮メッセージ（下流など）は、上記のメカニズムを使用する場合があります。
If a proxy detects that the next-hop proxy for a request is the proxy itself and that the request will not be sent through the network, the proxy MAY choose not to compress the request even if the URI contains the comp=sigcomp parameter.
プロキシがリクエストの次のホッププロキシがプロキシ自体であり、リクエストがネットワークを介して送信されないことを検出した場合、プロキシは、URIにcomp = sigcompパラメーターが含まれていてもリクエストを圧縮しないことを選択できます。
If a compressed SIP request arrives to a SIP server that does not understand SigComp, the server will not have any means to indicate the error to the client. The message will be impossible to parse, and there will be no Via header field indicating an address to send an error response.
圧縮されたSIPリクエストがSigCompを理解していないSIPサーバーに到着した場合、サーバーはクライアントにエラーを示す手段がありません。メッセージを解析することは不可能であり、エラー応答を送信するアドレスを示すヘッダーフィールドはありません。
If a SIP client sends a compressed request and the client transaction times out without having received any response, the client SHOULD retry the same request without using compression. If the compressed request was sent over a TCP connection, the client SHOULD close that connection and open a new one to send the uncompressed request. Otherwise the server would not be able to detect the beginning of the new message.
SIPクライアントが圧縮リクエストを送信し、クライアントのトランザクションが応答を受けずにタイムアウトする場合、クライアントは圧縮を使用せずに同じリクエストを再試行する必要があります。圧縮リクエストがTCP接続を介して送信された場合、クライアントはその接続を閉じて、非圧縮リクエストを送信するために新しい接続を開きます。それ以外の場合、サーバーは新しいメッセージの始まりを検出できません。
This section provides the augmented Backus-Naur Form (BNF) of both parameters described above.
このセクションでは、上記の両方のパラメーターの拡張されたバックナウル形式（BNF）を提供します。
The compression URI parameter is a "uri-parameter", as defined by the SIP ABNF (Section 25.1 of [1]):
圧縮URIパラメーターは、SIP ABNF（[1]のセクション25.1）で定義されている「URI-Parameter」です。
compression-param = "comp=" ("sigcomp" / other-compression)
other-compression = token
The Via compression parameter is a "via-extension", as defined by the SIP ABNF (Section 25.1 of [1]):
viaの圧縮パラメーターは、SIP ABNF（[1]のセクション25.1）で定義されているように、「via-Extension」です。
via-compression = "comp" EQUAL ("sigcomp" / other-compression) other-compression = token
via-compression = "comp" equal（ "sigcomp" / other-compression）other-compression = token
The following example illustrates the use of the parameters defined above. The call flow of Figure 1 shows an INVITE-200 OK-ACK handshake between a UAC and a UAS through two proxies. Proxy P1 does not Record-Route but proxy P2 does. Both proxies support compression, but they do not use it by default.
次の例は、上記のパラメーターの使用を示しています。図1のコールフローは、2つのプロキシを通じてUACとUASの間の招待-200 OK-ackハンドシェイクを示しています。プロキシP1はレコードルートではありませんが、プロキシP2は行います。両方のプロキシは圧縮をサポートしますが、デフォルトでは使用しません。
UAC P1 P2 UAS
|(1)INVITE(c) | | |
|------------>| (2) INVITE | |
| |------------>| (3) INVITE |
| | |------------>|
| | | (4) 200 OK |
| | (5) 200 OK |<------------|
|(6)200 OK(c) |<------------| |
|<------------| | |
| | (7)ACK(c) | |
|-------------------------->| (8) ACK |
| | |------------>|
| | | |
| | | |
Figure 1: INVITE transaction through two proxies
図1：2つのプロキシを通じてトランザクションを招待します
Messages (1), (6) and (7) are compressed (c).
メッセージ（1）、（6）、および（7）は圧縮されます（c）。
We provide a partial description of the messages involved in this call flow below. Only some parts of each message are shown, namely the Method name, the Request-URI and the Via, Route, Record-Route and Contact header fields. We have not used a correct format for these header fields. We have rather focus on the contents of the header fields and on the presence (or absence) of the "comp=sigcomp" parameter.
以下のこのコールフローに含まれるメッセージの部分的な説明を提供します。各メッセージの一部、つまりメソッド名、リクエスト-URI、VIA、ルート、レコードルート、コンタクトヘッダーフィールドの一部のみが表示されます。これらのヘッダーフィールドに正しい形式を使用していません。ヘッダーフィールドの内容と、「comp = sigcomp」パラメーターの存在（または不在）に焦点を当てています。
(1) INVITE UAS
Via: UAC;comp=sigcomp
Route: P1;comp=sigcomp
Contact: UAC;comp=sigcomp
P1 is the outbound proxy of the UAC, and it supports SigComp. The UAC is configured to send compressed traffic to P1, and therefore, it compresses the INVITE (1). In addition, the UAC wants to receive future requests and responses for this dialog compressed. Therefore, it adds the comp=Sigcomp parameter to the Via and to the Contact header fields.
P1はUACのアウトバウンドプロキシであり、SigCompをサポートしています。UACは圧縮トラフィックをP1に送信するように構成されているため、招待状（1）を圧縮します。さらに、UACは、このダイアログが圧縮された将来のリクエストと応答を受け取りたいと考えています。したがって、comp = sigcompパラメーターをviaとコンタクトヘッダーフィールドに追加します。
(2) INVITE UAS
Via: P1
Via: UAC;comp=sigcomp
Route: P2
Contact: UAC;comp=sigcomp
P1 forwards the INVITE (2) to P2. P1 does not use compression by default, so it sends the INVITE uncompressed to P2.
P1は招待（2）をp2に転送します。P1はデフォルトで圧縮を使用しないため、P2に圧縮されていない招待を送信します。
(3) INVITE UAS
Via: P2
Via: P1
Via: UAC;comp=sigcomp
Record-Route: P2
Contact: UAC;comp=sigcomp
P2 forwards the INVITE (3) to the UAS. P2 supports compression, but it does not use it by default. Therefore, it sends the INVITE uncompressed. P2 wishes to remain in the signalling path and therefore it Record-Routes.
P2は招待（3）をUASに転送します。P2は圧縮をサポートしますが、デフォルトでは使用しません。したがって、それは招待されていない招待を送信します。P2は、シグナリングパスにとどまることを望んでいるため、記録的なルートを希望します。
(4) 200 OK Via: P2 Via: P1 Via: UAC;comp=sigcomp Record-Route: P2 Contact: UAS
(4) 200 OK Via：P2 Via：P1 via：uac; comp = sigcomp Record-route：P2連絡先：UAS
The UAS generates a 200 OK response and sends it to the host in the topmost Via, which is P2.
UASは200 OK応答を生成し、最上部のホストに送信します。これはP2です。
(5) 200 OK
Via: P1
Via: UAC;comp=sigcomp
Record-Route: P2;comp=sigcomp
Contact: UAS
P2 receives the 200 OK response. P2 Record-Routed, so it inspects the Route set for this dialog. For requests from the UAS towards the UAC (the opposite direction than the first INVITE), the next hop will be the Contact header field of the INVITE, because P1 did not Record-Route. That Contact identified the UAC:
P2は200 OK応答を受け取ります。P2が記録されているため、このダイアログのルートセットを検査します。UASからUACへのリクエスト（最初の招待とは反対の方向）の場合、次のホップは招待状のコンタクトヘッダーフィールドになります。その連絡先はUACを特定しました：
Contact: UAC;comp=sigcomp
Since the UAC wants to receive compressed requests (Contact of the INVITE), P2 assumes that the UAC would also like to send compressed requests (Record-Route of the 200 OK). Therefore, P2 modifies its entry in the Record-Route header field of the 200 OK (5). In the INVITE (3), P2 did not used the comp=sigcomp parameter. Now it adds it in the 200 OK (5). This will allow the UAC sending compressed requests within this dialog.
UACは圧縮リクエスト（招待状の連絡）を受信したいため、P2はUACが圧縮リクエストを送信したいと思っています（200 OKの記録的なルート）。したがって、P2は、200 OK（5）のレコードルートヘッダーフィールドへのエントリを変更します。Invite（3）では、P2はcomp = sigcompパラメーターを使用しませんでした。これで、200 OK（5）に追加します。これにより、UACがこのダイアログ内で圧縮要求を送信することができます。
(6) 200 OK
Via: UAC;comp=sigcomp
Record-Route: P2;comp=sigcomp
Contact: UAS
P1 sends the 200 OK (6) compressed to the UAC because the Via header field contained the comp=sigcomp parameter.
P1は、viaヘッダーフィールドにcomp = sigcompパラメーターが含まれているため、200 ok（6）がUACに圧縮されたものを送信します。
(7) ACK UAS
Via: UAC;comp=sigcomp
Route: P2;comp=sigcomp
Contact: UAC;comp=sigcomp
The UAC sends the ACK (7) compressed directly to P2 (P1 did not Record-Route).
UACは、ACK（7）をP2に直接圧縮します（P1は記録的ではありませんでした）。
(8) ACK UAS
Via: P2
Via: UAC;comp=sigcomp
Contact: UAC;comp=sigcomp
P2 sends the ACK (8) uncompressed to the UAS.
P2はACK（8）をUASに非圧縮します。
A SIP entity receiving a compressed message has to decompress it and to parse it. This requires slightly more processing power than only parsing a message. This implies that a denial of service attack using compressed messages would be slightly worse than an attack with uncompressed messages.
圧縮メッセージを受信するSIPエンティティは、それを解凍し、それを解析する必要があります。これには、メッセージを解析するよりもわずかに多くの処理能力が必要です。これは、圧縮メッセージを使用したサービス拒否攻撃が、非圧縮メッセージを使用した攻撃よりもわずかに悪化することを意味します。
An attacker inserting the parameter comp=sigcomp in a SIP message could make a SIP entity send compressed messages to another SIP entity that did not support SigComp. Appropriate integrity mechanisms should be used to avoid this attack.
SIPメッセージにパラメーターcomp = sigcompを挿入する攻撃者は、SIPエンティティがSigcompをサポートしていない別のSIPエンティティに圧縮メッセージを送信する可能性があります。この攻撃を回避するために、適切な整合性メカニズムを使用する必要があります。
This document defines the "comp" uri-parameter and via-extension. New values for "comp" are registered by the IANA at http://www.iana.org/assignments/sip-parameters when new signalling compression schemes are published in standards track RFCs. The IANA Considerations section of the RFC MUST include the following information, which appears in the IANA registry along with the RFC number of the publication.
このドキュメントでは、「comp」uri-parameterとvia-Extensionを定義します。「comp」の新しい値は、http://www.iana.org/assignments/sip-parametersでIANAによって登録されます。RFCのIANAに関する考慮事項セクションには、IANAレジストリに表示されるRFC番号とともに、次の情報を含める必要があります。
o Name of the compression scheme.
o 圧縮スキームの名前。
o Token value to be used. The token MAY be of any length, but SHOULD be no more than ten characters long.
o 使用するトークン値。トークンは任意の長さであるかもしれませんが、長さ10文字以下でなければなりません。
The only entry in the registry for the time being is:
当分の間、レジストリの唯一のエントリは次のとおりです。
Compression scheme Token Reference
--------------------- --------- ---------
Signaling Compression sigcomp RFC 3486
Allison Mankin, Jonathan Rosenberg and Miguel Angel Garcia-Martin provided valuable comments on this memo.
アリソン・マンキン、ジョナサン・ローゼンバーグ、ミゲル・エンジェル・ガルシア・マルティンは、このメモに関する貴重なコメントを提供しました。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z. and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[2] Price、R.、Bormann、C.、Christoffersson、J.、Hannu、H.、Liu、Z。、およびJ. Rosenberg、「Signaling Compression（Sigcomp）」、RFC 3320、2003年1月。
[3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[4] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート3：ドメイン名システム（DNS）データベース」、RFC 3403、2002年10月。
[5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[5] Gulbrandsen、A.、Vixie、P。and L. Esibov、「サービスの場所（DNS SRV）を指定するためのDNS RR」、RFC 2782、2000年2月。
[6] Schulzrinne, H., "DHCP option for SIP servers", Work in Progress.
[6] Schulzrinne、H。、「SIPサーバーのDHCPオプション」、進行中の作業。
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Gonzalo Camarillo Ericsson Advanced Signaling Research Lab。Fin-02420 Jorvas Finland
EMail: Gonzalo.Camarillo@ericsson.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。