翻訳している文書

勉強のために翻訳したものを公開しています。訳の内容については保証できませんので、参考にする場合はご注意ください。

RFC 3588 Diameter Base Protocol

2009/05/09 1章だけ完了

RFC 4320 Session Initiation Protocol(SIP)の非INVITEトランザクションについて認識された問題を解決するアクション

2009/05/24 本文は完了

RFC 4321 Session Initiation Protocol(SIP)の非INVITEトランザクションに関連付けられて認識されている問題

2009/05/24 本文は完了

ETSI TS 183 017 AF-SPDF間におけるポリシー情報交換のためのDIAMETERプロトコル仕様

2009/05/19 5章の途中まで完了。ETSIの文書は公開していいのかどうか不明。。。

TR-069: Wikipedia

2009/07/06 Wikipediaの記事を翻訳。実際の技術仕様は量が多いのでおいおい

MS-CFB: Compound File Binary File Format NEW!

2009/10/12 2章まで完了。

RFC3261を読み解こう: 再送のまとめ

Timerについて前回まとめたので、今回は再送のロジックについてまとめます。再送の動作もRFC3261読んだだけでは全くイメージできませんからね。状態機械だけ見てイメージできる人がいるんでしょうか。うらやましい。

INVITEの再送動作(300～699応答の場合)

• INVITEの再送はUDPでのみ行います。
• INVITEを受信したUAは200ms以内に最終応答が返却できる保証がなければ100を返送しなければなりません(MUST)。普通そんな保証はないのでよほどの理由がない限り100を返送します。
• INVITEを受信したUAはINVITEの再送を受信する度に直前の暫定応答を再送します。が、100は再送されません。なぜなら100はサーバトランザクションがProceeding状態のときに扱う暫定応答に含まれていないからです(RFC3261 17.2.1 Figure.2参照)。
• INVITEを受信したUAはProceedingにいる間なら任意のタイミングで何度でも暫定応答を送信できます。
• 暫定応答を受信したUAはINVITEEの再送を停止し、最終応答を待ちます。
• 300～699の最終応答の再送はUDPでのみ行います。
• 300～699の最終応答に対するACKは1つのINVITEトランザクションの中のものとして扱われます。
• 300～699の最終応答を受信したUAはその度にACKを再送します。
• ACKを受信したUAはConfirmedになり、再送されてくるACKを待ち受けて破棄します。
• どのUAもTerminatedになったらトランザクションを直ちに解放します。
• Terminatedになった後に受信した信号は全て新規のものとして扱います。

INVITEの再送動作(200応答の場合)

• INVTEの最終応答が200の場合、UASは最終応答送信時に、UACは最終応答受信時にTerminatedに移行します。ただし、これだとINVITEがフォークされていた場合に後から来た応答に対応できないため、Timer LとTimer Mが新しく定義されています。がまだ正式な仕様になっていないため説明は割愛します。
• 200は300～699と違い、UAS→UACのエンドエンドで流通するため、UASのみが生成できます(プロキシは200を生成してはいけません)。
• 200は300～699と違い、トランザクションの外で再送されます。その再送のタイミングはTimer Gと同じなのですが、なぜか再送用のタイマや再送T.Oのタイマは定義されていません(RFC3261 13.3.1.4参照)。
• UACのみがACKを生成でき、200を受信する度にACKを再送します。

非INVITEの動作

• 非INVITEのサーバトランザクションもINVITEサーバトランザクションと同じような動作をしますが、非INVITEサーバトランザクションにはなぜかTryingステートがあります
• 非INVITEサーバトランザクションはRFC3261上、暫定応答を送信してもいいことになっていますが、RFC4320(和訳)で色々な条件付きで禁止されています。この記事はRFC3261に関する説明と言うことで割愛します。
• 非INVITEトランザクションでは200とそれ以外の応答とで動作の違いはありません。
• 非INVITEクライアントトランザクションでは、暫定応答や最終応答を受信しても、リクエストの再送を継続します(UDPに限り)。
• 最終応答の再送はリクエストの再送契機で行われます。だから暫定応答を受信してもリクエストの再送を止めないのです。

RFC3261を読み解こう: Timerのまとめ

SIPのRFC3261にはたくさんのタイマ(Timer)が定義されていますが、本文内のあちこちに書かれていて、結局どのタイミングでどのタイマがいくつに設定されるのか、いまいちよくわかりません。本稿ではRFC3261に散りばめられたタイマについてまとめ、上記の問題を払拭します。

まずは「付録A タイマ値表(英語)」にちょっと補足したものを以下に示します。なお、これ以降RFC3261内の「信頼性のないトランスポート」を意味する箇所をUDP、「信頼性のあるトランスポート」を意味する箇所をTCPと表記することにします。また各タイマのn回目に更新された値を「A_n」のように表現していますが、これは本稿で便宜上定義するもので、RFC3261内に同様な記述はありません。

タイマ値表

タイマ	設定値	説明
T1	500ms	RTTの推定値です。限定的なネットワークでない限り500ms以下は推奨されません(NOT RECOMMENDED)。一方、応答に時間がかかることが分かっている場合は500msより大きくすることが推奨されています(RECOMMENDED)。UACとUASそれぞれのT1値が異なる場合がありえますが、UAC、UAS共に相手のT1値を知ることはできません(≒知る仕組みがありません)。
T2	4s	INVITEリクエスト以外の全ての再送処理における、最大再送間隔を表します。初期値は4sと規定されていますが、他の値にしていいのかどうかはRFC3261には規定されていません。
T4	5s	既に処理が終わったメッセージの再送を受け取るための時間です。このタイマが有効な間は該当の再送メッセージを再送として受け取り、タイマが満了すると新規レスポンスとして処理します。初期値は5sと規定されていますが、他の値にしていいのかどうかはRFC3261には規定されていません。
Timer A	A0 = T1 An = An-1×2	INVITEの再送の為のタイマ。このタイマが満了するたびにINVITEを再送し、値を更新します。UDPでのみ左記の設定値が適用され、TCPでは常に0(=再送しない)となります。理屈上無限に大きくなりそうですが、Timer B(=64s×T1)が満了するとその時点でトランザクション終了となるため、実際はA5までしかないのが普通です。
Timer B	64s×T1 (UDP/TCP)	INVITEクライアントトランザクションがCalling状態でいられる最大時間。満了するとトランザクション状態がTerminatedへ遷移します。いかなるトランスポートでも64s×T1となります。
Timer C	Timer C > 180s	プロキシがINVITEを転送するときにクライアントトランザクションに設定するタイマ。180s(3分)より大きい値でなければならず(MUST)、暫定応答を受信するたびに180sより大きい値で更新されます。満了した場合は、暫定応答をもらっていればCANCEL送出、暫定応答がなければ408応答を受信したかのように動作しなければなりません(MUST)。なお、プロキシのみに設定される値で、UACには設定しません。これは、UACは任意にCANCELでINVITEトランザクションを終了できますが、プロキシは(Timer Cがなければ)自発的にCANCELを送出する契機を持っていないからです。
Timer D	> 32s (UDP) = 0s (TCP)	INVITEトランザクションで300～699を受信したときに、ACKを返却する期間。
Timer E	E0 = T1 En = min(En-1×2, T2)	非INVITEトランザクションにおいて、UACがリクエストを再送するためのタイマです。最大でT2にしかならない、という点を除いて、Timer Aと同じです。
Timer F	64s×T1 (UDP/TCP)	非INVITEトランザクションにおいて、UACが暫定応答をもらうまでのタイマです。Timer Bと同じです。
Timer G	G0 = T1 Gn = min(Gn-1×2, T2)	INVITEサーバトランザクションにおいて、UASが300～699までの最終応答を再送するためのタイマです。Timer Eと同じ更新の仕方をします。
Timer H	64s×T1 (UDP/TCP)	INVITEサーバトランザクションにおいて、UASが300～699までの最終応答に対するACKを受信するまでの時間です。UDP、TCPともに左記の値にします。満了した場合はTerminatedに遷移してトランザクションを破棄します。
Timer I	= T4 (UDP) = 0s (TCP)	INVITEサーバトランザクションにおいて、UASがACKの再送に備える時間です。満了する以外に消滅契機はありません。満了した場合はTerminatedに遷移してトランザクションを破棄します。
Timer J	= 64s×T1 (UDP) = 0s (TCP)	非INVITEサーバトランザクションがCompleted状態にいられる時間。Timer Hと同じ役割。
Timer K	= T4 (UDP) = 0s (TCP)	非INVITEクライアントトランザクションがCompleted状態にいられる時間。Timer Dと同じ役割。
Timer L	64s×T1	RFC3261非掲載。トランザクション状態がAcceptedのときに受理済みのINVITEの再送を受け付けるタイマ。詳しくはdraft-sparks-sip-invfixを参照。
Timer M	64s×T1	RFC3261非掲載。200の再送またはフォークされた先からの200の再送を受け付けるタイマ。詳しくはdraft-sparks-sip-invfixを参照。

AAAプロトコルの目的は何処。。。役に立たないRFCを読んでしまった悲劇

勉強のためにRFC3588の翻訳をやっていますが、翻訳って大変ですね。読んで意味が分かることと、それを日本語で表現するのとは、雲泥の差があることが分かりました。

ところで、このRFCを翻訳している理由は、IMSで使われているGq'インターフェイスを理解するための前段として「そもそもDiameterとは何か？」ということを知らなくては、という重い突きからなのですが、1章を訳し終わって気づきました。

ここには大した情報が書いてない！！

1章の途中で気づいていましたが、ほとんど役に立たないものを訳してしまいました。。。

欲しかった情報は、「Diameterが具体的に何をするプロトコルなのか」をやり取りするデータの実体名で知りたかったのですが、全く書いてありませんね。

そもそもこのRFCはどんな構成しているんですかね。1章には「1.2. Approach to Extensibility(拡張性へのアプローチ)」という箇所がありますが、そんなものはずっと後でしょう。まずAAAのそれぞれの機能は具体的に何をすることなのかを書いておいてくださいよ。このRFC内では一貫して「認証を行うアプリケーションは」とか書いてありますが、それが何をすることなのか、さっぱり分かりません。

SIPのRFC3261もそうですが、汎用性を持たせるためか、そのプロトコルが何の情報を伝えるものなのかがはっきり書いていないんですよね。SIPであれば「発着のIPアドレスとポート、そしてメディア情報(≒SDP)」という通信を開始するために必要な情報を共有する、というのが目下の目的です。ダイアログを作るとかルート情報を確立させるとかは二の次です。まずはIPアドレスとポートとメディアです。それを概要か1章の最初に書いておいてほしいですよね。

まーRFCも技術仕様とは言いながら、テキスト形式で展開している時点で、参考情報程度の効力しかないんでしょうかね。今のご時世に全くそぐわないやり方で、ものごとをまとめようとする姿勢が大変残念です。