Network Working Group G. Camarillo
Request for Comments: 3486 Ericsson
Category: Standards Track February 2003
Compressing 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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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.
この文書は、一つ以上のセッション開始プロトコル（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サーバに要求を送信するSIP [1]クライアントは通常、サーバのドメイン名のDNSルックアップを実行します。 NAPTR [4]またはSRV [5]レコードがサーバーで使用可能な場合は、クライアントはそれを望んでいるサービスの種類を指定することができます。この文脈でのサービスは、SIP（例えば、UDP、TCPまたはSCTP）によって使用されるトランスポートプロトコルです。サポートしているSIPサーバは、例えば、三つの異なるトランスポートプロトコルは、三つの異なる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:
例えば、圧縮をシグナリングのためにTLSトランスポート・セキュリティおよびSigCompのためのトランスポートとしてTCPやSCTPをサポートし、サーバは、以下に示す8 DNSエントリが必要になります。
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要素は、同じポートで圧縮し、圧縮されていないメッセージを受信するために準備する必要があります。これは、すべての圧縮されたメッセージの最上位ビットでクッキーに基づいて分離を行います。
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つのパラメータ、SIP URIの一方とViaヘッダーフィールドのための他の定義します。以下の実施例に示すように、両方のパラメータのフォーマットは、同じです。
sip:alice@atlanta.com;comp=sigcomp Via: SIP/2.0/UDP server1.foo.com:5060;branch=z9hG4bK87a7;comp=sigcomp
SIP：alice@atlanta.com; COMP = SigCompのビア：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は、要求のリクエストURIまたはRouteヘッダーフィールドのエントリです。
If the next-hop URI contains the parameter comp=sigcomp, the client SHOULD compress the request using SigComp as defined in [2].
ネクストホップ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.
ネクストホップ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を追加すべきである= ContactヘッダーフィールドのURIへのSigCompそれは、ユーザエージェントクライアントがある場合。クライアントがプロキシである場合、それはRecord-RouteヘッダーフィールドにそのURIにパラメータCOMP =にSigCompを追加する必要があります。
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.
ユーザエージェントクライアントが圧縮リクエストを送信する場合は、ContactヘッダーフィールドのURIにパラメータカンプ=にSigCompを追加する必要があります。レコード・ルートが圧縮リクエストを送信するプロキシは、それがRecord-Routeヘッダフィールドに、その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.
クライアントが圧縮リクエストを送信する場合は、Viaヘッダーフィールドの一番上のエントリにパラメータCOMP =にSigCompを追加する必要があります。
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のサポートしていますが、場合には、サーバがそれをサポートするかどうかわからない場合は、それが圧縮された応答を受信したいと思い、このクライアントは、Viaヘッダーフィールドの一番上のエントリにパラメータ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は、Record-Routeヘッダフィールドから得られます。ダイアログ外リクエストを送信するクライアントは、要求に3XXまたは485応答のContactヘッダフィールドに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にもたらす最大の利益の一つは、最初のユーザーが確立するセッションを待っているとき、ダイアログのINVITEを圧縮する機能です。そのため、クライアントは、ユーザーがセッションを確立することを決定する前に、そのアウトバウンドプロキシから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
この問題の一つの解決策は、手動設定です。しかし、時には自動のやり方で構成されたクライアントを持つことが必要です。残念ながら、SIPクライアントの設定のための現在のメカニズム（DHCPを使用して、例えば、[6]）を提供することができません
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.
URIのパラメータを持つクライアント。この場合、クライアントはそのアウトバウンドプロキシに圧縮されていないOPTIONSリクエストを送るべきです。アウトバウンドプロキシはOPTIONSに200 OK応答のContactヘッダフィールドに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]は、プロキシが自分宛OPTIONS要求に応答する方法を定義していません。これは、サーバーだけが特定のユーザ宛OPTIONSへの対応方法を説明します。 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.
Contactヘッダフィールドは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.
我々は彼らに宛てOPTIONSへの応答のプロキシサーバーにこの動作を拡張します。彼らは、プロキシを連絡するための代替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を登録することができるので、圧縮された（でも初期のINVITE）着信要求を受信しても問題ないことに留意されたいです。ユーザーのすべての着信要求は、圧縮を使用して、この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ヘッダーフィールドのパラメータでホストに送信されます。最上位Viaヘッダーフィールドは、パラメータ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.
非対称圧縮を回避するために、プロキシは応答におけるそれらのレコードルートエントリを書き換える必要がある（すなわち、2つのSIPエンティティは、他の方向の一方方向に圧縮要求と非圧縮の要求を交換します）。レコードルートを行うプロキシは、（第9の例を参照）、この応答をトリガーし、要求に応答し、ContactヘッダフィールドにRecord-Routeヘッダフィールドを検査します。これは、ルートセット内の次の（ユーザエージェントクライアントに近い）の上流ホップのURIを探します。このURIは、パラメータCOMP =のSigCompが含まれている場合、プロキシはRecord-Routeヘッダフィールド内のそのエントリにCOMP =のSigCompを追加する必要があります。このURIは、パラメータCOMP =のSigCompが含まれていない場合（それが存在する場合）、プロキシはRecord-Routeヘッダフィールド内のエントリから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が含まれている場合と同じように、ユーザエージェントサーバは、応答のContactヘッダーフィールドに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つのレコードルートエントリを追加します。このように、プロキシは応答にRecord-Routeヘッダーフィールドを書き換える必要はありません。
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サーバに到着した場合、サーバはクライアントにエラーを示すために、あらゆる手段を持っていません。メッセージは構文解析することは不可能となり、エラー応答を送信するアドレスを示すないViaヘッダーフィールドは存在しないであろう。
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]):
SIP ABNFによって定義されるような圧縮URIパラメータは、「URIパラメータ」である（セクション25.1 [1]）。
compression-param = "comp=" ("sigcomp" / other-compression) other-compression = token
圧縮PARAM =「COMP =」（「のSigComp」/他の圧縮）他の圧縮トークン=
The Via compression parameter is a "via-extension", as defined by the SIP ABNF (Section 25.1 of [1]):
ビア圧縮パラメータである「ビア拡張」、SIP ABNFによって定義される（セクション25.1 [1]）。
via-compression = "comp" EQUAL ("sigcomp" / other-compression) other-compression = token
圧縮ビア=「COMP」EQUAL（「のSigComp」/他の圧縮）他の圧縮トークン=
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との間のINVITE、200 OK、ACKハンドシェイクを示します。プロキシP1は、レコードルートではなく、プロキシP2はありません。どちらのプロキシが圧縮をサポートしていますが、彼らは、デフォルトではそれを使用しないでください。
UAC P1 P2 UAS
P1 P2のUAC
|(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つのプロキシ経由INVITEトランザクション
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
私たちは、以下のこのコールフローに関係するメッセージの部分的な説明を提供します。のみ各メッセージの一部を示している、すなわち、メソッド名、リクエストURIを介して、ルート、レコードルートと
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.
Contactヘッダーフィールド。我々は、これらのヘッダーフィールドの正しい形式を使用していません。我々は、むしろヘッダフィールドの内容と「COMP = SigCompの」パラメータの存在（または不在）に焦点を当ててきました。
(1) INVITE UAS Via: UAC;comp=sigcomp Route: P1;comp=sigcomp Contact: UAC;comp=sigcomp
COMP = SigCompの経路; UAC：P1、COMP = SigCompの連絡先：UAC; COMP =のSigComp（1）UASビアINVITE
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に圧縮トラフィックを送信するように構成され、したがって、それは、INVITE圧縮する（1）。また、UACは圧縮され、このダイアログの今後のリクエストとレスポンスを受信したいです。したがって、それは介して、ContactヘッダーフィールドにCOMP =のSigCompパラメータを追加します。
(2) INVITE UAS Via: P1 Via: UAC;comp=sigcomp Route: P2 Contact: UAC;comp=sigcomp
COMP = SigCompの経路; UAC：P2との接触：UAC; COMP = SigCompのP1を介して、（2）UASビアINVITE
P1 forwards the INVITE (2) to P2. P1 does not use compression by default, so it sends the INVITE uncompressed to P2.
P1はP2に（2）INVITE転送します。 P1は、デフォルトでは、圧縮を使用していないので、P2に非圧縮のINVITEを送信します。
(3) INVITE UAS Via: P2 Via: P1 Via: UAC;comp=sigcomp Record-Route: P2 Contact: UAC;comp=sigcomp
COMP = SigCompのレコードルート; UAC：P2との接触：UAC; COMP = SigCompのP2を介し：P1（3）を介してUASビアINVITE
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は、UASに（3）INVITEを転送します。 P2は圧縮をサポートしていますが、デフォルトでは使用しません。したがって、それは非圧縮のINVITEを送信します。 P2は、シグナリングパスに残り、従って、それがレコードルートをすることを望みます。
(4) 200 OK Via: P2 Via: P1 Via: UAC;comp=sigcomp Record-Route: P2 Contact: UAS
（4）200 OK経由：P2を介し：P1を介し：UAC; COMP = SigCompのレコードルート：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
（5）200 OK経由：P1を介し：UAC; COMP = SigCompのレコードルート：P2; COMP = SigCompの連絡先：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のレコードルーティングので、ルートは、このダイアログに設定された検査。 P1は、レコードルートをしなかったため、UAC（最初のINVITEは反対の方向）に向かってUASからの要求を、ネクストホップは、INVITEのContactヘッダーフィールドであろう。その連絡先は、UACを識別しました：
Contact: UAC;comp=sigcomp
連絡先：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は圧縮された要求（INVITEの連絡先）を受けたいので、P2は、UACはまた、圧縮された要求（200 OKのレコード・ルート）を送信したいことを想定しています。したがって、P2は、200 OK（5）のRecord-Routeヘッダフィールド内のエントリを変更します。 INVITE（3）、P2は、COMP = SigCompのパラメータを使用しませんでした。今では200 OK（5）でそれを追加します。これは、UACは、このダイアログ内で圧縮された要求を送信できるようになります。
(6) 200 OK Via: UAC;comp=sigcomp Record-Route: P2;comp=sigcomp Contact: UAS
（6）200 OK経由：UAC; COMP = SigCompのレコードルート：P2; COMP = SigCompの連絡先：UAS
P1 sends the 200 OK (6) compressed to the UAC because the Via header field contained the comp=sigcomp parameter.
Viaヘッダフィールドは、COMP = SigCompのパラメータが含まれていたため、P1はUACに圧縮された200 OK（6）を送信します。
(7) ACK UAS Via: UAC;comp=sigcomp Route: P2;comp=sigcomp Contact: UAC;comp=sigcomp
（7）ACK UAS経由：UAC; COMP = SigCompの経路：P2; COMP = SigCompの連絡先：UAC; COMP =のSigComp
The UAC sends the ACK (7) compressed directly to P2 (P1 did not Record-Route).
UACは、P2に直接圧縮ACK（7）（P1は、レコードルートをしなかった）を送信します。
(8) ACK UAS Via: P2 Via: UAC;comp=sigcomp Contact: UAC;comp=sigcomp
（8）ACK UAS経由：P2を介し：UAC; COMP = SigCompの連絡先：UAC; COMP =のSigComp
P2 sends the ACK (8) uncompressed to the UAS.
P2は、UASの非圧縮ACK（8）を送信します。
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エンティティを作ることができるSIPメッセージのパラメータCOMP =にSigCompを挿入する攻撃者は、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パラメータを介して、拡張子を定義します。新しいシグナリング圧縮方式が標準化トラックのRFCで公開されたときに「COMP」のための新しい値がhttp://www.iana.org/assignments/sip-parametersでIANAによって登録されています。 RFCのIANA Considerations部は、出版のRFC番号とともにIANAレジストリに表示される次の情報を含まなければなりません。
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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 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]価格、R.、ボルマン、C.、Christoffersson、J.、ハンヌ、H.、劉、Z.およびJ.ローゼンバーグ、 "シグナリング圧縮（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]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、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.、 "ダイナミックな委譲発見システム（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.及び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
ゴンサロ・カマリロエリクソン高度なシグナリング研究所。 FIN-02420 Jorvasフィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。