RFC3486 日本語訳
3486 Compressing the Session Initiation Protocol (SIP). G. Camarillo. February 2003. (Format: TXT=24181 bytes) (Updated by RFC5049) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Camarillo Request for Comments: 3486 Ericsson Category: Standards Track February 2003
コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 3486年のエリクソンカテゴリ: 標準化過程2003年2月
Compressing the Session Initiation Protocol (SIP)
セッション開始プロトコルを圧縮します。(一口)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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つ以上のSession Initiationプロトコル(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
1. 序論… 2 2. 操作の概要… 3 3. SIPのためのSigComp実装… 3 4. 要求をサーバに送ります… 3 4.1 コンピュータでSIPかSIPS URIを入手するのはsigcompと等しいです… 4 5. 応答をクライアントに送ります… 5 6. 記録的なルート設定を倍にしてください… 6 7. 誤り状況… 6 8. BNFを増大させます… 7 9. 例… 7 10. セキュリティ問題… 10 11. IANA問題… 10 12. 承認… 10 13. 標準の参照… 10 14. 有益な参照… 11 15. 作者のアドレス… 11 16. 完全な著作権宣言文… 12
Camarillo Standards Track [Page 1] RFC 3486 Compressing SIP February 2003
2003年2月に一口を圧縮するキャマリロ標準化過程[1ページ]RFC3486
1. Introduction
1. 序論
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サーバ(例えば、3つの異なったトランスポート・プロトコル)は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.
特定用途層のプロトコルによってサポートされたトランスポート・プロトコルの数が劇的に成長しないのが見通されるので、1輸送あたり1つの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)は、8つのDNSエントリーを必要とするでしょう、したがって、例えばTCPとSCTPをサポートしたサーバは以下に記載しました:
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を使用するこの方法がスケーラブルでないことは、明確です。 したがって、合図圧縮のサポートを言い表す応用層メカニズムが必要です。
Camarillo Standards Track [Page 2] RFC 3486 Compressing SIP February 2003
2003年2月に一口を圧縮するキャマリロ標準化過程[2ページ]RFC3486
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の両方がTLSにTCPの上でTCPだけと異なったポートを使用する歴史的な理由でそれに注意してください、このソリューションは現在のところ、もうスケーラブルであると考えられませんが。
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要素は、同じポートに関する圧縮されて解凍されたメッセージを受け取るように準備される必要があるでしょう。 それはあらゆる圧縮されたメッセージの最上のビットでクッキーに基づく逆多重化を実行するでしょう。
2. Overview of operation
2. 操作の概要
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.
2つのタイプに関するSIPメッセージがあります。 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のための1つとViaヘッダーフィールドのためのもう片方を定義します。 両方のパラメタの形式は以下の例に示されるように同じです:
sip:alice@atlanta.com;comp=sigcomp Via: SIP/2.0/UDP server1.foo.com:5060;branch=z9hG4bK87a7;comp=sigcomp
一口: alice@atlanta.com;comp はsigcomp Viaと等しいです: 一口/2.0/UDP server1.foo.com: 5060; ブランチ=z9hG4bK87a7; コンピュータ=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における、このパラメタ(コンピュータ=sigcomp)の存在は、要求がSigCompを使用することで圧縮されなければならないのを示します、[2]で定義されるように。 Viaヘッダーフィールドにおける、コンピュータ=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.
したがって、コンピュータ=sigcompの存在は、URIかViaヘッダーフィールドによって特定されたSIP実体がSigCompをサポートするのを示して、圧縮されたメッセージを受け取っても構わないと思っています。 コンピュータ=sigcompに「サポート」と同様に「意欲」を意味させると、一時にSigCompを使用するかどうかに関する決定に影響を及ぼすSIPメッセージの受信機は許容されます。
3. SigComp implementations for SIP
3. SIPのためのSigComp実装
Every SIP implementation that supports SigComp MUST implement the procedures described in this document.
SigCompをサポートするあらゆるSIP実装が本書では説明された手順を実装しなければなりません。
4. Sending a Request to a Server
4. 要求をサーバに送ります。
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はRouteヘッダーフィールドにおける要求かエントリーのRequest-URIです。
If the next-hop URI contains the parameter comp=sigcomp, the client SHOULD compress the request using SigComp as defined in [2].
次のホップURIがパラメタコンピュータ=sigcompを含んでいるなら、クライアントSHOULDは、[2]で定義されるようにSigCompを使用することで要求を圧縮します。
Camarillo Standards Track [Page 3] RFC 3486 Compressing SIP February 2003
2003年2月に一口を圧縮するキャマリロ標準化過程[3ページ]RFC3486
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であるなら、要求SHOULDです以前圧縮されていて、それが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.
圧縮されていた状態で要求を送るかどうかにかかわらず、クライアントがUAC方向が圧縮したUAS->での同じ対話の中にその後の要求を受け取りたいなら、このクライアントSHOULDはそれがユーザエージェントのクライアントであるならパラメタコンピュータ=sigcompをContactヘッダーフィールドにおけるURIに加えます。 クライアントはプロキシであり、それはSHOULDです。パラメタコンピュータがRecord-ルートヘッダーフィールドにおけるURIへの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.
ユーザエージェントのクライアントが発信するなら、aは要求を圧縮しました、それ。SHOULDは、パラメタコンピュータがContactヘッダーフィールドにおけるURIへのsigcompと等しいと言い足します。 プロキシであるなら、Record-ルートが圧縮された要求を送って、それがSHOULDであることはRecord-ルートヘッダーフィールドにおけるURIにコンピュータ=sigcompを加えます。
If a client sends a compressed request, it SHOULD add the parameter comp=sigcomp to the topmost entry of the Via header field.
クライアントが発信するなら、aは要求を圧縮しました、それ。SHOULDは、パラメタコンピュータがViaヘッダーフィールドの最上のエントリーへの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をサポートするかどうかを知りませんが、サーバがそれをサポートするといけなかったので圧縮された応答を受けたいなら、このクライアントSHOULDは、パラメタコンピュータがViaヘッダーフィールドの最上のエントリーへのsigcompと等しいと言い足します。 しかしながら、上で述べられるとして、要求は圧縮されていないでしょう。
4.1 Obtaining a SIP or SIPS URI with comp=sigcomp
4.1 コンピュータ=sigcompでSIPかSIPS URIを入手すること。
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.
対話を確立するとき、対話の中の要求において、Record-ルートヘッダーフィールドからsigcompコンピュータがある次のホップURI=パラメタを得ます。 また、対話の外で要求を送るクライアントはコンピュータ=sigcompで3xxのContactヘッダーフィールドか要求への485応答で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つは対話の初期のINVITEを圧縮する能力です、ユーザが、セッションが確立されるのを待っているとき。 したがって、クライアントはユーザが、セッションを確立すると決める前に彼らの外国行きのプロキシからコンピュータ=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
この問題への1つの解決は手動の構成です。 しかしながら、時々、自動ファッションでクライアントを構成させるのが必要です。 SIPクライアント構成のための残念ながら現在のメカニズム、(例えば、DHCP[6])が提供するのを許さない使用
Camarillo Standards Track [Page 4] RFC 3486 Compressing SIP February 2003
2003年2月に一口を圧縮するキャマリロ標準化過程[4ページ]RFC3486
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パラメタをもっているクライアント。 この場合、クライアントSHOULDは解凍されたOPTIONS要求を外国行きのプロキシに送ります。 外国行きのプロキシはOPTIONSへの200OK応答におけるContactヘッダーフィールドにおける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:
RFC3261[1]はプロキシがどうそれ自体に扱われたOPTIONS要求に応じるべきであるかを定義しません。 それは特定のユーザに扱われたOPTIONSにサーバがどう反応するかを説明するだけです。 RFC3261のセクション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.
分野が3xx応答で200(OK)応答で存在していて、同じ意味論を持っているかもしれないヘッダーを連絡してください。 すなわち、彼らは1セットの代替名とユーザに届くメソッドを記載するかもしれません。
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に応じるプロキシサーバへのこの振舞いを広げます。 彼らは、プロキシに連絡するために1セットの代替の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.
入って来る要求(初期のINVITEsさえ)が圧縮した受信が問題でないことに注意してください、コンピュータ=があるユーザエージェント缶のREGISTER a SIP URIが彼らの記録係でsigcompするので。 圧縮を使用することでユーザを求めるすべての入って来る要求をこのSIP URIに送るでしょう。
5. Sending a Response to a Client
5. 応答をクライアントに送ります。
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ヘッダーフィールドがパラメタを含んでいるなら、コンピュータはsigcompと等しく、応答はSHOULDです。圧縮されます。 さもなければ、応答を圧縮してはいけません。
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実体と解凍された要求)を避けるために、プロキシは、応答における彼らのRecord-ルートエントリーを書き直す必要があります。 Recordルートを実行しているプロキシは応答におけるRecord-ルートヘッダーフィールドとこの応答の引き金となった要求におけるContactヘッダーフィールドを点検します(セクション9で例を見てください)。 それはルートセットで次の上流(ユーザエージェントのクライアントについて、より近い)のホップのURIを探します。 このURIがパラメタコンピュータ=sigcompを含んでいるなら、プロキシSHOULDはRecord-ルートヘッダーフィールドにおけるエントリーにコンピュータ=sigcompを加えます。 このURIがパラメタコンピュータ=sigcompを含んでいないなら、プロキシSHOULDはRecordルートヘッダーフィールドにおけるエントリーからコンピュータ=sigcomp(それが存在しているなら)を取り外します。
Camarillo Standards Track [Page 5] RFC 3486 Compressing SIP February 2003
2003年2月に一口を圧縮するキャマリロ標準化過程[5ページ]RFC3486
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がパラメタコンピュータ=sigcompを含んだなら、同じ道、ユーザエージェントサーバSHOULDは応答のContactヘッダーフィールドにコンピュータ=sigcompを加えます。
6. Double Record-Routing
6. 二重記録的なルート設定
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つのRecord-ルートエントリーを特定の要求に追加しますが、何人かのプロキシが、Recordルートの書き直しを避けるために彼らの2人を加えます。 二重Record-ルート設定の典型的な例は2つのネットワークの間のファイアウォールとして務めるSIPプロキシです。 要求がどのネットワークから来るかによって、それは異なったインタフェースにプロキシによって受け取られるでしょう。 プロキシは1つのインタフェースと2番目の1つのために1つのRecord-ルートエントリーをもう片方のインタフェースに加えます。 このように、プロキシは応答のRecord-ルートヘッダーフィールドを書き直す必要はありません。
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.
受信するプロキシが、対話(例えば、上流)の半面でメッセージを圧縮して、メカニズムが上で説明した反対側(例えば、川下)5月の使用からメッセージを解凍しました。
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がコンピュータを含んでも要求を圧縮しないのを選ぶかもしれないのとsigcompパラメタと等しいです。
7. Error Situations
7. エラー状態
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クライアントが圧縮された要求とクライアントトランザクション回数をどんな応答も受けたことのない外に送るなら、圧縮を使用しないで、クライアントSHOULDは同じ要求を再試行します。 TCP接続の上に圧縮された要求を送ったなら、クライアントSHOULDは、解凍された要求を送るためにその接続を終えて、新しいものを開きます。 さもなければ、サーバは新しいメッセージの始まりを検出できないでしょう。
Camarillo Standards Track [Page 6] RFC 3486 Compressing SIP February 2003
2003年2月に一口を圧縮するキャマリロ標準化過程[6ページ]RFC3486
8. Augmented BNF
8. 増大しているBNF
This section provides the augmented Backus-Naur Form (BNF) of both parameters described above.
このセクションは上で説明された両方のパラメタの増大しているBN記法(BNF)を提供します。
The compression URI parameter is a "uri-parameter", as defined by the SIP ABNF (Section 25.1 of [1]):
SIP ABNFによって定義されるように圧縮URIパラメタは「uri-パラメタ」です。([1])について25.1を区分してください:
compression-param = "comp=" ("sigcomp" / other-compression)
other-compression = token
「コンピュータ=」(他の"sigcomp"/圧縮)他の圧縮-param=圧縮はトークンと等しいです。
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-compression = "comp" EQUAL ("sigcomp" / other-compression)
other-compression = token
圧縮の=「コンピュータ」EQUAL(他の"sigcomp"/圧縮)の他の圧縮はトークンと等しいです。
9. Example
9. 例
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握手を示しています。 Record-ルートではなく、P1がするプロキシにもかかわらず、プロキシP2はそうします。 両方のプロキシは圧縮をサポートしますが、彼らはデフォルトでそれを使用しません。
UAC P1 P2 UAS
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 |
| | |------------>|
| | | |
| | | |
| (1) (c)を招待してください。| | | |、-、-、-、-、-、-、-、-、-、-、--、>| (2) 招待| | | |、-、-、-、-、-、-、-、-、-、-、--、>| (3) 招待| | | |、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| (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
私たちは以下でのこの呼び出し流動にかかわるメッセージの部分的な記述を提供します。 そしてRoute、それぞれのメッセージのいくつかだけの部分が示されてすなわち、Method名と、Request-URIとViaである、Record-ルート。
Camarillo Standards Track [Page 7] RFC 3486 Compressing SIP February 2003
2003年2月に一口を圧縮するキャマリロ標準化過程[7ページ]RFC3486
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.
ヘッダーフィールドに連絡してください。 私たちはこれらのヘッダーフィールドに正しい形式を使用していません。 私たちはヘッダーフィールドのコンテンツの上と、そして、「コンピュータ=sigcomp」パラメタの存在(または、不在)の上にむしろ焦点を持っています。
(1) INVITE UAS
Via: UAC;comp=sigcomp
Route: P1;comp=sigcomp
Contact: UAC;comp=sigcomp
(1) 以下を通ってUASを招待してください。 UAC; コンピュータはsigcompルートと等しいです: P1; コンピュータはsigcomp接触と等しいです: UAC; コンピュータ=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に送るために構成されます、そして、したがって、それはINVITE(1)を圧縮します。 さらに、UACは圧縮されたこの対話のための今後の要求と応答を受け取りたがっています。 したがって、それはViaと、そして、Contactヘッダーフィールドにコンピュータ=Sigcompパラメタを加えます。
(2) INVITE UAS
Via: P1
Via: UAC;comp=sigcomp
Route: P2
Contact: UAC;comp=sigcomp
(2) 以下を通ってUASを招待してください。 以下を通ってP1 UAC; コンピュータはsigcompルートと等しいです: P2接触: UAC; コンピュータ=sigcomp
P1 forwards the INVITE (2) to P2. P1 does not use compression by default, so it sends the INVITE uncompressed to P2.
P1はINVITE(2)をP2に送ります。 P1がデフォルトで圧縮を使用しないので、それはP2に解凍されたINVITEを送ります。
(3) INVITE UAS
Via: P2
Via: P1
Via: UAC;comp=sigcomp
Record-Route: P2
Contact: UAC;comp=sigcomp
(3) 以下を通ってUASを招待してください。 以下を通ってP2 以下を通ってP1 UAC; コンピュータはsigcompの記録的なルートと等しいです: P2接触: UAC; コンピュータ=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はINVITE(3)をUASに送ります。 P2は圧縮をサポートしますが、それはデフォルトでそれを使用しません。 したがって、それは解凍されたINVITEを送ります。 P2は経路としたがって、それがRecord発送する合図に残りたがっています。
(4) 200 OK
Via: P2
Via: P1
Via: UAC;comp=sigcomp
Record-Route: P2
Contact: UAS
以下を通って(4)200OK 以下を通ってP2 以下を通ってP1 UAC; コンピュータはsigcompの記録的なルートと等しいです: P2接触: UAS
Camarillo Standards Track [Page 8] RFC 3486 Compressing SIP February 2003
2003年2月に一口を圧縮するキャマリロ標準化過程[8ページ]RFC3486
The UAS generates a 200 OK response and sends it to the host in the topmost Via, which is P2.
UASは200OK応答を生成して、最上のViaのホストにそれを送ります。(ViaはP2です)。
(5) 200 OK
Via: P1
Via: UAC;comp=sigcomp
Record-Route: P2;comp=sigcomp
Contact: UAS
以下を通って(5)200OK 以下を通ってP1 UAC; コンピュータはsigcompの記録的なルートと等しいです: P2; コンピュータは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は200OK応答を受けます。 P2が記録して掘ったので、この対話に設定されて、それはRouteを点検します。 UACに向かったUASからの要求、(逆方向、最初のINVITE)、次のホップはINVITEのContactヘッダーフィールドになるでしょう、P1がどんなRecord-ルートもしなかったので。 そのContactはUACを特定しました:
Contact: UAC;comp=sigcomp
接触: UAC; コンピュータ=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が圧縮された要求(200OKの記録的なルート)を送りたがっていると仮定します。 したがって、P2は200OK(5)のRecord-ルートヘッダーフィールドにおけるエントリーを変更します。 (3)、P2がそうするINVITEでは、使用されないで、コンピュータはsigcompパラメタと等しいです。 今、それは200OK(5)でそれを加えます。 これはこの対話の中で送付の圧縮された要求をUACに許すでしょう。
(6) 200 OK
Via: UAC;comp=sigcomp
Record-Route: P2;comp=sigcomp
Contact: UAS
以下を通って(6)200OK UAC; コンピュータはsigcompの記録的なルートと等しいです: P2; コンピュータはsigcomp接触と等しいです: UAS
P1 sends the 200 OK (6) compressed to the UAC because the Via header field contained the comp=sigcomp parameter.
P1はViaヘッダーフィールドがsigcompコンピュータ=パラメタを含んだのでUACに圧縮された200OK(6)を送ります。
(7) ACK UAS
Via: UAC;comp=sigcomp
Route: P2;comp=sigcomp
Contact: UAC;comp=sigcomp
(7) 以下を通ってACK UAS UAC; コンピュータはsigcompルートと等しいです: P2; コンピュータはsigcomp接触と等しいです: UAC; コンピュータ=sigcomp
The UAC sends the ACK (7) compressed directly to P2 (P1 did not Record-Route).
UACは直接P2に圧縮されたACK(7)を送ります(P1はどんなRecord-ルートもしませんでした)。
(8) ACK UAS
Via: P2
Via: UAC;comp=sigcomp
Contact: UAC;comp=sigcomp
(8) 以下を通ってACK UAS 以下を通ってP2 UAC; コンピュータはsigcomp接触と等しいです: UAC; コンピュータ=sigcomp
P2 sends the ACK (8) uncompressed to the UAS.
P2はUASに解凍されたACK(8)を送ります。
Camarillo Standards Track [Page 9] RFC 3486 Compressing SIP February 2003
2003年2月に一口を圧縮するキャマリロ標準化過程[9ページ]RFC3486
10. Security Considerations
10. セキュリティ問題
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.
パラメタコンピュータ=sigcompをSIPメッセージに挿入する攻撃者はSIP実体にSigCompをサポートしなかった別のSIP実体に圧縮されたメッセージを送らせることができました。 適切な保全メカニズムは、この攻撃を避けるのに使用されるべきです。
11. IANA Considerations
11. IANA問題
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.
このドキュメントは、「コンピュータ」uri-パラメタを定義して、拡大でそうします。 新しい合図圧縮技術が標準化過程RFCsで発行されるとき、「コンピュータ」のための新しい値は http://www.iana.org/assignments/sip-parameters にIANAによって示されます。 RFC MUSTの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 使用されるべきトークン値。 トークンがどんな長さのそうですがも、SHOULDは10のキャラクタが切望するほどそうではありません。
The only entry in the registry for the time being is:
当分の間間の登録における唯一のエントリーは以下の通りです。
Compression scheme Token Reference --------------------- --------- --------- Signaling Compression sigcomp RFC 3486
圧縮技術Token Reference--------------------- --------- --------- シグナリングCompression sigcomp RFC3486
12. Acknowledgements
12. 承認
Allison Mankin, Jonathan Rosenberg and Miguel Angel Garcia-Martin provided valuable comments on this memo.
アリソン・マンキン、ジョナサン・ローゼンバーグ、およびミゲル・Angelガルシア-マーチンはこのメモの貴重なコメントを提供しました。
13. Normative References
13. 引用規格
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
Camarillo Standards Track [Page 10] RFC 3486 Compressing SIP February 2003
2003年2月に一口を圧縮するキャマリロ標準化過程[10ページ]RFC3486
[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)」、RFC3320、2003年1月。
[3] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
14. Informative References
14. 有益な参照
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403, October
2002.
[4] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、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」、RFC2782、2000年2月。
[6] Schulzrinne, H., "DHCP option for SIP servers", Work in
Progress.
[6]Schulzrinne、H.、「SIPサーバのためのDHCPオプション」、ProgressのWork。
15. Author's Address
15. 作者のアドレス
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
ゴンサロキャマリロエリクソンは合図研究研究室を進めました。 フィン-02420Jorvasフィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール: Gonzalo.Camarillo@ericsson.com
Camarillo Standards Track [Page 11] RFC 3486 Compressing SIP February 2003
2003年2月に一口を圧縮するキャマリロ標準化過程[11ページ]RFC3486
16. Full Copyright Statement
16. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Camarillo Standards Track [Page 12]
キャマリロ標準化過程[12ページ]
一覧
スポンサーリンク
