Network Working Group G. Camarillo Request for Comments: 3486 Ericsson Category: Standards Track February 2003 セッション開始プロトコル(SIP)の圧縮 Compressing the Session Initiation Protocol (SIP) 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2003).All Rights Reserved. 概要 本文書は、1つ以上のセッション開始プロトコル(Session Initiation Protocol/SIP)メッセージで圧縮が望ましいことをシグナリングする仕組みに ついて説明する。また、SIPエンティティに圧縮したSIPメッセージを送信する のが適切な場合についても説明する。 目次 1. はじめに .................................................. 2 2. 操作の概要 ................................................ 3 3. SIPのSigComp実装 .......................................... 3 4. サーバーへのリクエスト送信 ................................ 3 4.1 comp=sigcompを含むSIPまたはSIPS URIの取得 ............ 4 5. クライアントへの応答送信 .................................. 5 6. 二重のRecord-Route ........................................ 6 7. エラーの状況 .............................................. 6 8. Augmented 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 1. はじめに リクエストをSIPサーバーに送信するSIP [1]クライアントは、一般的に、その サーバーのドメイン名についてDNS検索を実行する。NAPTR [4]レコードまたは SRV [5]レコードがサーバーで使用できる場合、クライアントは必要なサービ スの種類を指定できる。この文脈でのサービスとは、SIPで使用するトランス ポートプロトコルである(UDP、TCP、SCTPなど)。たとえば、3つの異なるトラ ンスポートプロトコルをサポートするSIPサーバーは、3つの異なるDNSエント リを持つ。 特定のアプリケーション層プロトコルでサポートされるトランスポートプロト コルの数は、大幅に増加することはないと予想されるため、トランスポートご とにDNSエントリを持つことは、十分なスケーラブルな解決策と考えられる。 ただし、場合によっては、トランスポートプロトコルとアプリケーション層プ ロトコルの間に新しい層を含める必要がある。このような層の例を挙げると、 トランスポート層セキュリティと圧縮である。DNSを使用して、特定のサー バーに対するこのような層の可用性を検出した場合、そのサーバーに必要な DNSエントリの数は大幅に増加する。 たとえば、サーバーで、トランスポートにTCPとSCTP、トランスポートセキュ リティにTLS、シグナリング圧縮にSigCompをサポートする場合、以下のように 8個のDNSエントリが必要になる。 1. TCP、セキュリティなし、圧縮なし 2. TCP、セキュリティなし、SigComp 3. TCP、TLS、圧縮なし 4. TCP、TLS、SigComp 5. SCTP、セキュリティなし、圧縮なし 6. SCTP、セキュリティなし、SigComp 7. SCTP、TLS、圧縮なし 8. SCTP、TLS、SigComp このようなDNSの使用方法はスケーラブルでないことは明らかである。した がって、シグナリング圧縮のサポートを示すアプリケーション層の仕組みが必 要になる。 Camarillo Standards Track [Page 2] RFC 3486 Compressing SIP February 2003 歴史的な理由から、HTTPとSIPの両方どちらも、TCP上のTLSとTCPとで異な るポートを使用しているが、現時点では、この解決方法はスケーラブルと 考えられていない、ということに注意。 圧縮をサポートするSIP要素を用意して、同じポートで圧縮メッセージと非圧 縮メッセージを受信する必要がある。各圧縮メッセージの最上位ビットにある cookieに基づいて、逆多重化(demultiplexing)が実行される。 2. 操作の概要 SIPメッセージには、SIPリクエストとSIP応答という2種類がある。クライアン トは、URIのホスト部に対してSIPリクエストを送信し、サーバーはViaヘッ ダーフィールドのsent-byパラメータにあるホスに対して応答を送信する。 本文書では、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 URIにこのパラメータ(comp=sigcomp)が存在する場合、[2]で定義されるよう に、リクエストはSigCompを使用して圧縮する必要があることを示す。Viaヘッ ダーフィールドにcomp=sigcompが存在する場合、応答はSigCompを使用して圧 縮する必要があることを示す。 したがって、comp=sigcompが存在する場合、URIまたはViaヘッダーフィールド で識別されるSIPエンティティは、SigCompをサポートし、圧縮メッセージを受 信する意思があることを示す。comp=sigcompに「サポート」だけでなく、「進 んで受け入れる意思がある」意味を持たせることで、SIPメッセージの受信側 は、ある時点でSigCompを使用するかどうかの判断に影響を与えることができ る。 3. SIPのSigComp実装 SigCompをサポートするSIP実装はいずれも、本文書で説明される手順を実装し なければならない[MUST]。 4. サーバーへのリクエスト送信 リクエストは、URIのホスト部に送信される。このURI(次ホップのURIとも呼ば れる)は、リクエストのRequest-URIまたは、Routeヘッダーフィールドのエン トリである。 次ホップのURIに、パラメータcomp=sigcompが含まれる場合、クライアント は、[2]で定義されるSigCompを使用してリクエストを圧縮すべきである [SHOULD]。 Camarillo Standards Track [Page 3] RFC 3486 Compressing SIP February 2003 次ホップのURIがSIPS URIの場合、リクエストはTLS層に渡す前に圧縮すべきで ある[SHOULD]。 クライアントは、サーバーがSigCompをサポートしているかどうかがわからな い場合、圧縮リクエストをサーバーに送信してはならない[MUST NOT]。 送信リクエストが圧縮されているかどうかにかかわらず、クライアントが同じ ダイアログ内の以降のリクエストを、UAS->UAC方向で圧縮して受信したい場 合、このクライアントがユーザーエージェントクライアントであれば、パラ メータcomp=sigcompをContactヘッダーフィールドに追加すべきである [SHOULD]。クライアントがプロキシの場合、Record-Routeヘッダーフィールド のURIに、パラメータcomp=sigcompを追加すべきである[SHOULD]。 ユーザーエージェントクライアントが圧縮リクエストを送信する場合、パラ メータcomp=sigcompをContactヘッダーフィールドのURIに追加すべきである [SHOULD]。Record-Routeするプロキシが圧縮リクエストを送信する場合、 Record-RouteヘッダーフィールドのURIにcomp=sigcompを追加すべきである [SHOULD]。 クライアントが圧縮リクエストを送信する場合、パラメータcomp=sigcompを Viaヘッダーフィールドの先頭エントリに追加すべきである[SHOULD]。 クライアントは、サーバーがSigCompをサポートしているかどうかをわからな いが、サーバーがサポートしている場合には圧縮応答を受信したい場合、この クライアントは、Viaヘッダーフィールドの先頭エントリにパラメータcomp= sigcompを追加すべきである[SHOULD]。ただし、前述のように、リクエストは 圧縮されない。 4.1 comp=sigcompを含むSIPまたはSIPS URIの取得 あるダイアログ内のリクエストで、ダイアログが確立したときに、Record- Routeヘッダーフィールドからパラメータcomp=sigcompが指定された次ホッ プのURIを取得します。ダイアログ外でリクエストを送信するクライアント は、そのリクエストに対する3xxまたは485応答のContactヘッダーフィールド に含まれるcomp=sigcompで、SIP URIを取得することもできる。 ただし、一般的に、セッションを確立するクライアントは、メッセージの圧縮 を開始するためにダイアログが確立するまで待機したくないものである。 SigCompがSIPにもたらす最大の利点のひとつは、ユーザーが確立されるセッ ションを待機しているときに、ダイアログの最初のINVITEを圧縮できることで ある。したがって、クライアントは、ユーザーがセッションを確立することを 決定する前に、アウトバウンドプロキシからcomp=sigcomp URIを取得する手段 が必要である。 この問題の解決策のひとつは、手動設定である。ただし、場合によっては、自 動的な方法でクライアントを設定する必要がある。残念ながら、現在のSIPク ライアント設定の仕組み(DHCP [6]の使用など)では、クライアントにURIパラ Camarillo Standards Track [Page 4] RFC 3486 Compressing SIP February 2003 メータを提供することができない。この場合、クライアントは圧縮されていな いOPTIONSリクエストをアウトバウンドプロキシに送信すべきである [SHOULD]。アウトバウンドプロキシは、そのOPTIONSに対する200 OKの応答に 含まれるContactヘッダーフィールドのcomp=sigcompパラメータに、代替のSIP URIを提供することができる。クライアントは、圧縮を使用して同じアウトバ ウンドプロキシ経由で送信される以降のリクエストで、このURIを使用でき る。 RFC 3261 [1]では、プロキシあてに送信されたOPTIONSリクエストに対して、 プロキシがどのように応答すべきかについて定義されていない。単に、特定 ユーザーあてに送信されたOPTIONSに対してサーバーが応答する方法について 説明されているのみである。RFC 3261のセクション11.2には以下のように記載 されている。 Contactヘッダーフィールドは200 (OK)応答に含め、3xx応答と同じセマン ティクスを使用してもよい[MAY]。つまり、ユーザーに到達する代替の名前 とメソッドの一覧を指定することができる。 本文書では、この動作を、プロキシあてに送信されたOPTIONSに対するプロキ シサーバーの動作にも拡張する。代替のURIの一覧を指定して、プロキシに接 続してもよい[MAY]。 圧縮リクエスト(たとえ最初のINVITEでも)を受信することは問題ではない、と いうことに注意。ユーザーエージェントは、レジストラのcomp=sigcompでSIP URIをREGISTERできるためである。ユーザーに届くリクエストはすべて、圧縮 を使用してこのSIP URIに送信される。 5. クライアントへの応答送信 応答は、Viaヘッダーフィールドのsent-byパラメータのホストに送信される。 先頭のViaヘッダーフィールドにパラメータcomp=sigcompが含まれる場合、応 答は圧縮すべきである[SHOULD]。それ以外の場合、応答を圧縮してはならない [MUST NOT]。 非対称の圧縮(つまり、2つのSIPエンティティが一方向で圧縮リクエストを交 換し、別方向では非圧縮のリクエストを交換している場合)を回避するため に、プロキシは応答のRecord-Routeエントリを書き換える必要がある。Record -Routeを実行するプロキシは、応答のRecord-Routeフィールドと、この応答を トリガしたリクエストのContactヘッダーフィールドを調べる(セクション9の 例を参照)。ルートセット内にある次のアップストリーム(ユーザーエージェン トクライアントに近い)ホップのURIを検索する。このURIにパラメータcomp= sigcompが含まれる場合、プロキシはcomp=sigcompをRecord-Routeヘッダー フィールドのエントリに追加すべきである[SHOULD]。このURIにパラメータ comp=sigcompが含まれない場合、プロキシはRecord-Routeヘッダーフィールド のエントリにcomp=sigcompがあれば削除すべきである[SHOULD]。 Camarillo Standards Track [Page 5] RFC 3486 Compressing SIP February 2003 同様に、ユーザーエージェントサーバーは、ルートセット内にある次のアップ ストリームホップのURIにパラメータcomp=sigcompが含まれる場合、応答の Contactヘッダーフィールドにcomp=sigcompを追加すべきである[SHOULD]。 6. 二重のRecord-Route 通常、プロキシは、特定のリクエストに対してゼロまたは1個のRecord-Route エントリを追加するが、一部のプロキシは、Record-Routeの書き換えを防ぐた めに2つを追加することがある。二重のRecord-Routeの一般的な例は、2つの ネットワーク間でファイアウォールとして動作するSIPプロキシである。リク エストが送信されたネットワークがどちらかによって、プロキシの受信イン ターフェイスは変わる。プロキシは、1つ目のRecord-Routeエントリを一方の インターフェイスに追加し、2つ目のRecord-Routeエントリを別のインター フェイスに追加する。この方法では、プロキシは応答でRecord-Routeヘッダー フィールドを書き換える必要がない。 プロキシが、圧縮メッセージをダイアログの一方(アップストリームなど)から 受信し、もう一方(ダウンストリームなど)からは圧縮されていないメッセージ を受信する場合、上記の仕組みを使用してもよい[MAY]。 あるプロキシが、リクエストの次ホップのプロキシがそのプロキシ自身であ り、リクエストがネットワーク経由で送信されないことを検出した場合、URI にcomp=sigcompパラメータが含まれている場合でも、そのプロキシはリクエス トを圧縮しないことを選択してもよい[MAY]。 7. エラーの状況 圧縮されたSIPリクエストが、SigCompを理解しないSIPサーバーに到達した場 合、そのサーバーは、クライアントに対してエラーを示す手段が何もない。 メッセージの解析は不可能で、エラー応答を送信するアドレスがViaヘッダー フィールドに指定されない。 SIPクライアントは、何も応答を受信していない状態で、圧縮リクエストとク ライアントトランザクションの期限切れを送信する場合、圧縮を使用しないで 同じリクエストを再試行すべきである[SHOULD]。圧縮リクエストがTCP接続で 送信された場合、クライアントは接続を閉じ、新しい接続を開いて圧縮されて いないリクエストを送信すべきである[SHOULD]。そうしないと、サーバーは新 しいメッセージの開始を検出できない。 Camarillo Standards Track [Page 6] RFC 3486 Compressing SIP February 2003 8. Augmented BNF このセクションでは、上記の両パラメータのAugmented BNF (Backus-Naur Form)について説明する。 圧縮のURIパラメータは、SIP ABNF([1]のセクション25.1)で定義されているよ うに、「uri-parameter」である。 compression-param = "comp=" ("sigcomp" / other-compression) other-compression = token Viaの圧縮パラメータは、SIP ABNF([1]のセクション25.1)で定義されているよ うに、「via-extension」である。 via-compression = "comp" EQUAL ("sigcomp" / other-compression) other-compression = token 9. 例 次の例では、前述のように定義されているパラメータの用法を示す。図1の コールフローは、UACとUAS間(2つのプロキシを経由)のINVITE-200 OK-ACKのハ ンドシェイクを示す。プロキシP1は、Record-Routeを実行しないが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 | | | |------------>| | | | | | | | | 図1 : 2つのプロキシ間のINVITEトランザクション メッセージ(1)、(6)、および(7)は圧縮されている(c)。 このコールフローに関係するメッセージに含まれる記述の一部について、説明 する。各メッセージの一部のみ、つまりメソッド名、Request-URI、および Via、Route、Record-Route、Contactの各ヘッダーフィールドを示す。これら のヘッダーフィールドについて正しい書式は使用しなかった。ここでは、ヘッ ダーフィールドのコンテンツと、「comp=sigcomp」パラメータの存在(または 不在)の方に焦点を当てた。 (1) INVITE UAS Via: UAC;comp=sigcomp Route: P1;comp=sigcomp Contact: UAC;comp=sigcomp P1はUACのアウトバウンドプロキシであり、SigCompをサポートする。UACは、 圧縮したトラフィックをP1に送信するように設定されている。そのため、 INVITE (1)を圧縮する。さらに、UACは、このダイアログの以降のリクエスト および応答を圧縮された状態で受信することを希望している。したがって、 ViaとContactの各ヘッダーフィールドにcomp=Sigcompパラメータを追加する。 (2) INVITE UAS Via: P1 Via: UAC;comp=sigcomp Route: P2 Contact: UAC;comp=sigcomp P1はINVITE (2)をP2に転送する。P1は、デフォルトで圧縮を使用しないため、 非圧縮のINVITEをP2に送信する。 (3) INVITE UAS Via: P2 Via: P1 Via: UAC;comp=sigcomp Record-Route: P2 Contact: UAC;comp=sigcomp P2はINVITE (3)をUASに転送する。P2は圧縮をサポートしているが、デフォル トでは使用しない。そのため、非圧縮のINVITEを送信する。P2は、シグナリン グパスに残りたいため、Record-Routeを実行する。 (4) 200 OK Via: P2 Via: P1 Via: UAC;comp=sigcomp Record-Route: P2 Contact: UAS Camarillo Standards Track [Page 8] RFC 3486 Compressing SIP February 2003 UASは200 OK応答を生成し、先頭のViaのホスト(P2)に送信する。 (5) 200 OK Via: P1 Via: UAC;comp=sigcomp Record-Route: P2;comp=sigcomp Contact: UAS P2は200 OK応答を受信する。P2はRecord-Routeを実行するため、このダイアロ グのRouteセットを調べる。UASからUACへのリクエストの場合(最初のINVITEと は逆方向)、P1はRecord-Routeを実行しないため、次ホップはINVITEのContact ヘッダーフィールドになる。ContactでUACが識別される。 Contact: UAC;comp=sigcomp UACは圧縮リクエスト(INVITEのContact)を受信することを望んでいるため、P2 は、UACが圧縮リクエストの送信も望んでいると仮定する(200 OKのRecord- Route)。したがって、P2は200 OKのRecord-Routeヘッダーフィールドのエント リを修正する(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は、Viaヘッダーフィールドにcomp=sigcompパラメータが含まれるため、圧 縮された200 OK (6)をUACに送信する。 (7) ACK UAS Via: UAC;comp=sigcomp Route: P2;comp=sigcomp Contact: UAC;comp=sigcomp UACは圧縮されたACK (7)をP2に直接送信する(P1はRecord-Routeしない)。 (8) ACK UAS Via: P2 Via: UAC;comp=sigcomp Contact: UAC;comp=sigcomp P2は圧縮されていないACK (8)をUASに送信する。 Camarillo Standards Track [Page 9] RFC 3486 Compressing SIP February 2003 10. セキュリティの考慮事項 圧縮メッセージを受信するSIPエンティティは、そのメッセージを圧縮解除 し、解析する必要がある。そのため、メッセージを単に解析するよりもやや高 い処理能力が必要になる。つまり、圧縮メッセージを使用したDoS攻撃は、圧 縮されていないメッセージを使用した攻撃よりもやや悪質である。 悪意のあるユーザーがSIPメッセージにパラメータcomp=sigcompを挿入する と、SIPエンティティは圧縮されたメッセージをSigCompをサポートしていない SIPエンティティに送信してしまう可能性がある。適切な完全性保護の仕組み を使用して、この攻撃を回避すべきである。 11. IANA条項 本文書は、「comp」のuri-parameterとvia-extensionを定義する。新しいシグ ナリングの圧縮スキームが標準化過程のRFCで公開された場合、「comp」の新 しい値は、IANA(http://www.iana.org/assignments/sip-parameters)で登録さ れる。RFCのIANA条項セクションには、以下の情報を含めなければならない [MUST]。これは、公開されるRFC番号とともに、IANA登録に表示される。 o 圧縮スキームの名前。 o 使用するトークン値。このトークンの長さは任意でよい[MAY]が、10文 字を超えないようにすべきである[SHOULD]。 現時点の登録項目は、以下のみ。 圧縮スキーム トークン 参考文献 --------------------- --------- --------- Signaling Compression sigcomp RFC 3486 12. 謝辞 Allison Mankin、Jonathan Rosenberg、Miguel Angel Garcia-Martinの各氏か ら、本文書に貴重なコメントをいただいた。 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. Camarillo Standards Track [Page 10] RFC 3486 Compressing SIP February 2003 [2] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z. and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003. [3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997. 14. 有益な参考文献 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [6] Schulzrinne, H., "DHCP option for SIP servers", Work in Progress. 15. 著者の連絡先 Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland EMail: Gonzalo.Camarillo@ericsson.com Camarillo Standards Track [Page 11] RFC 3486 Compressing SIP February 2003 16. 完全な著作権表示 Copyright (C) The Internet Society (2003).All Rights Reserved. 本記述とその翻訳はコピーし他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著作 権表示およびこの節を付加するものはすべて、全体であってもその一部であっ ても、いっさいの制約を課されること無く、準備、複製、発表、配布すること ができる。しかし、この文書自体にはいかなる方法にせよ、著作権表示やイン ターネット協会もしくは他のインターネット関連団体への参照を取り除くなど の変更を加えてはならない。インターネット標準を開発するために必要な場合 は例外とされるが、その場合はインターネット標準化過程で定義されている著 作権のための手続きに従わなければならない。またRFCを英語以外の言語に翻 訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネット協会もしくはそ の継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ ト協会およびIETFは、この情報がいかなる権利も侵害していないという保証、 商用利用および特定目的への適合性への保証を含め、また、これらだけに限ら ずすべての保証について、明示的もしくは暗黙的の保証は行われない。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供されて いる。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Camarillo Standards Track [Page 12]