翻訳している文書

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

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章まで完了。

parityfec(parity FEC)

具体的な機能については不明ですが、エラー訂正(パリティ)用のMIMEタイプのようです。FECとはForward Error Correctionの略です。parityfecについてはRFC2733で定義されていて、RFC3009でMIMEタイプとしてaudio/parityfec、video/parityfec、text/parityfec、application/parityfecが定義されています。

なおparityfecというMIMEタイプは、RFC5109で廃止されています。なぜ今さら投稿したかというと、T.38の勧告の中で出てきたからです。T.38自体RFC2327ベースで書かれているため、こうした古い記事も残っていたのでしょう。

ですので、今さら覚える必要はありません。RFC5109を読んでください。

使い方

fmtpに下記のようなフォーマットの文字列を設定します。

a=fmtp:<number> <port> <network type> <address type> <connection address>

使用例

v=0
o=hamming 2890844526 2890842807 IN IP4 126.16.64.4
s=FEC Seminar
c=IN IP4 224.2.17.12/127
t=0 0
m=audio 49170 RTP/AVP 0 78
a=rtpmap:78 parityfec/8000
a=fmtp:78 49172 IN IP4 224.2.17.12/127
m=video 51372 RTP/AVP 31 79
a=rtpmap:79 parityfec/8000
a=fmtp:79 51372 IN IP4 224.2.17.13/127

PCMU(G.711 mu-law) / PCMA(G.711 A-law)

PCMU/PCMAは言わずと知れた一般的なIP電話のコーデックです。G.711 u-lawとも呼ばれます。RFC4856のSection 2.1.18にSDPでの指定方法が登録されています。一方PCMAはPCMUよりダイナミックレンジが若干狭いようです。Wikipediaによれば規定により、1カ国でもA-lawを使う国があれば、国際接続ではA-lawが使われるそうです。PCMAはRFC4856のSection 2.1.17にSDPについて記述があります。

概要

G.711の仕様書は以下にあります。

• (PDF)ITU-T Recommendation G.711

G.711のサンプリングは8000Hzで1サンプル1バイトですので、64kbpsになることが一般的です。

PCMUもPCMAもG.711の1つですが、PCMUはmu-lawアルゴリズムを、PCMAはA-lawアルゴリズムを使用する、という違いがあります。

(RFC3551) 4.5.14 PCMA and PCMU (拙訳)

PCMAとPCMUはITU-Tの勧告でG.711と規定されている。オーディオデータは対数スケーリング(logarithmic scaling)後にサンプル毎に8bitでエンコードされる。PCMUはmu-lawスケーリングを、PCMAはA-lawスケーリングを意味している。詳細な記述はJayantとNollによって提供されている。[15] 各G.711オクテットはRTPパケット内に整列(octet-aligned)されるべきである(SHALL)。各G.711オクテットの符号ビットはRTPパケット内のオクテットの最上位ビットに一致するべきである(SHALL)(つまり、G.711のサンプル数の推測はホストマシン上でオクテットとして扱われ、符号ビットはホストマシンのフォーマットによって定義される、オクテットの最上位ビットとすべきである)。G.711の56kb/sと48kb/sモードはRTPへは適用されない。PCMAとPCMUは常に8ビットでサンプリングされ、転送されなければならないからである(MUST)。

使い方

PCMU/PCMAのパラメータ

パラメータ名	説明
メディアタイプ	audio
メディアサブタイプ	PCMU PCMA
必須パラメータ
rate	RTPタイムスタンプのクロックレートで、これはサンプリングレートに一致します。一般的には8000ですが他のレートが指定されることもあります。仕様上も「名目上1秒間に8000サンプル。誤差は±50ppmまで」と言っているだけで、制限については書かれていません。チャンネル数を2ch(=ステレオ)にする場合は、サンプリングレートを2倍(16000)にします。こうすることで、左右交互にデータがインタリーブされ、8000Hzの音が左右から出るのと同じ効果が得られます。
オプションパラメータ
channels	何本のオーディオストリームが使用されるかを示します。デフォルトは1、ステレオは2です。それ以外も指定可能です。インタリーブは1バイトサンプルされる毎に実施されます。チャンネル順序はRFC3551で規定されています。「チャンネル数毎のチャンネル順序」にRFC3551からの抜粋を示します。
ptime	RFC4566参照
maxptime	RFC4566参照

チャンネル数毎のチャンネル順序

チャンネル数	記述	チャンネル
2	stereo	l	r
3		l	r	c
4		l	c	r	S
5		Fl	Fr	Fc	Sl	Sr
6		l	lc	c	r	rc	S
凡例 l left r right c center S surround F front R rear

使用例

サンプリング周波数8000のPCMUとPCMAでコーデックネゴシエーションするオファーをする場合。

v=0
o=john 51050101 51050101 IN IP4 offhost.example.com
s=-
c=IN IP4 offhost.example.com
t=0 0
m=audio 5004 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

サンプリング周波数16000でPCMUのステレオ(2チャンネル)をオファーをする場合。アンサーでこのオファーに同意した場合、左右から8000Hzでサンプリングされた音声が流れます。

v=0
o=john 51050101 51050101 IN IP4 offhost.example.com
s=-
c=IN IP4 offhost.example.com
t=0 0
m=audio 5004 RTP/AVP 0
a=rtpmap:0 PCMU/16000/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に限り)。
• 最終応答の再送はリクエストの再送契機で行われます。だから暫定応答を受信してもリクエストの再送を止めないのです。

ゼロから学ぶSIP: 第04回 SIPメッセージの中身と通信方式

SIPはSIPメッセージと言うテキスト形式のデータをやりとりすることで、セッションを確立します。具体的に言うと、TCPやUDPの様なトランスポートプロトコルのデータ部(=ペイロード)にSIPメッセージを載せ、これを通信者同士で送受信し合うことで、必要な情報を共有していきます。

SIPメッセージはその内容によってリクエスト(要求)とレスポンス(応答)の2種類があります。リクエストはセッションを開始/変更/終了しようするときにUACから送出されるSIPメッセージです。レスポンスはUASからリクエストの成功または失敗を返却するためのSIPメッセージです。

SIPメッセージは大きく分けて以下の3つの部分で構成されています。

スタートライン

リクエストの場合はリクエストの種類(メソッド)、レスポンスの場合は成功または失敗を表すコード(ステータスコード)を記述。

ヘッダ部

SIP自身のプロトコルで必要となる情報(=発着の論理アドレス、ルーチングの為の情報等)を記述。

ボディ部

セッションを確立させる為の情報(=発着のIPアドレス/ポート番号、メディア情報等)を記述

スタートラインはリクエスト、レスポンスでそれぞれ以下の様な形式で記述します。

リクエスト

INVITE sip:bob@biloxi.com SIP/2.0

レスポンス

SIP/2.0 200 OK

ヘッダやSDPの詳細の説明はここでは割愛します(基本的すぎるので)。RFC3261に記述されているSIPメッセージの例を参考までに示しておきます。

リクエストの例(INVITE)

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142

レスポンスの例

SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131

セッションを確立させるための情報はSession Description Protocol: SDPというプロトコルに従って記述するのが一般的です。SDPは現在はRFC4566で定義されています。

SIPでセッションを確立させるには、まず発信者がSIPメッセージにメディア情報を記述したリクエストを出し、着信者がその中から対応可能なメディアを選択したレスポンスを返却することで、通信に使用するメディア情報を共有します。このようにセッションを開始するためにSIPメッセージにメディア情報を載せることをオファーといい、それに対して対応可能なメディア情報を返却することをアンサーといいます。このオファーアンサーモデルについてはRFC3264で定義されています。

ボディ部にはSDPを記述しますが、SDPはオファーもしくはアンサーのときのみ必要なので、それ以外の場合はボディ部は空になります。

ここではリクエストでオファーし、レスポンスでアンサーする例をあげましたが、場合によってはレスポンスでオファーし別の何らかの方法を使ってアンサーを返却することもできます。詳しくはRFC3264を参照してください。

ボディ部にはセッションで利用されるメディア情報をSDPで記述しオファーアンサーで共有する、ということは上述しましたが、ヘッダ部に記述される情報はどのように利用されるのでしょうか。実はここからがSIPの真髄です。ルーティングやらダイアログやらターゲットやら、複雑な話がたくさん出てきます。それらについては次回以降で説明していきます。

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を参照。

ゼロから学ぶSIP: 第03回 SIPの登場人物、UAとSIPサーバ

SIPを使った通信をするときに登場する登場人物(装置)は以下の通りです。

• 通信者(UA: User Agent)
  • 通信元(UAC: User Agent Client)
  • 通信先(UAS: User Agent Server)
• SIPサーバ(またはプロキシサーバ)

通信をするユーザのことをUAと呼びます。電話の場合は加入者(の端末)のことです。チャットの場合はサービスに入っているメンバのことです。

UAが通信を開始しようとするとき、そのUAをUACと呼び、通信に招待されるUAをUASと呼びます。つまりUACとUASの間のセッションを成立させることがSIPの目的であると言えます。UACとUASがお互いのIPアドレス/ポート番号とメディアの情報をSIPメッセージをやり取りすることで共有できれば、目的達成ができるというわけです。なお、UACとUASは論理的な立場のようなもので、1回のトランザクション(リクエストとレスポンスのセット)が終了するとなくなります。そして次にリクエストを出すときに改めてUAC、UASが定義されます。そのため、リクエストを出す方向が逆になればUAC、UASも逆転します。

しかしSIPメッセージをやり取りするためには、SIPメッセージをやり取りするためのIPアドレス/ポート番号が必要になります(ややこしい。。)。例えば電話の場合、通信先(着信先)の電話番号は知っているかもしれませんが、IPアドレスなんて知らないことが多いです。つまり、UACがUASのIPアドレスを知らなくても、電話番号やメールアドレス(チャットの場合)さえあれば相手にSIPメッセージが届く仕組みが必要になります。そこで登場するのがSIPサーバ(プロキシサーバ)と呼ばれるSIPメッセージを中継するサーバです。

SIPサーバは、UACからのSIPメッセージ(正確にはリクエスト)に記述されている電話番号やメールアドレスのような論理的なアドレスを基に、適切なUASや別のSIPサーバへとSIPメッセージを中継します。具体的にはリクエストのSIPメッセージ内に記述されているRequest-URIやToヘッダを見て経路選択を行います。この経路選択のことをルーティングと言います。SIPサーバはリクエストだけでなく、レスポンスも中継します。

SIPサーバは、どんなリクエストをどこにルーティングすればいいかを知っています(そう設定されています)。電話の場合、それは電話番号と接続先(UAS or 他のSIPサーバ)を関連付けた単純なリスト(あるいはデータベース)のようなものですが、どんなリクエストをどこにルーティングするのかはSIPでは規定されていない為、どこへどうつなぐかはSIPサーバの胸三寸です。また時と場合によって接続する先を変えてもかまいません。これは例えば、同じ電話番号へかけても、接続先が輻輳している場合にガイダンスサーバへつないだり、着信先が収容変え(番号ポータビリティ)で他の事業会社に収容されているかもしれないからです。いづれにしても、(リクエストがエラーにならない限り、)SIPサーバが中継動作を繰り返すことで、必ずどこかのUASへと辿りつくことができます。

上記のSIPサーバの動作によって、UACは通信先の論理的なアドレスをSIPメッセージに記述し、それをSIPサーバに渡すだけで、ルーティングをSIPサーバに任せることができます。UACはリクエストを書くことだけに専念すればいいわけです。

SIPサーバの動作はとてもたくさんあり、全てを説明することはできませんが、基本的には上述の通り、受信したリクエストの論理的なアドレスを見て適切にルーティングすることです。

まとめると、SIPを使って通信をするときには、発信者(UAC)、着信者(UAS)という2つのUA以外に、SIPサーバ(プロキシサーバ)という中継サーバがあり、これがルーティング機能を全て賄ってくれるので、UAはSIPサーバからのリクエスト、レスポンスだけを処理すればいいことになります。

H.248(Megaco): 第01回 MegacoとMGCPとH.248

MGを操作するプロトコルには、Megaco、MGCP、H.248があります。ややこしいので最初に整理しておきます。下図はMegaco、MGCP、H.248の発生と変遷を表したものです。

上記の中のMegacoとMGCPは、RFC2805で定義されている「Media Gateway Control Protocol Architecture」という要求事項を実装したプロトコルです。先にMGCPができて、あとからMegacoができました。そのため、Megacoの方をより正式なものにしようという動きが強いです(MGCPは標準ではなく情報文書(Informational)です。IP電話用語集参照)。

MGを操作するプロトコルとしてMegacoを標準化させようとする一方で、Megacoの管轄が、もともと音頭を取っていたIETFから(なぜか)ITU-Tに移されます。これにより、IETFはMegacoからは手を引き、ITU-Tが音頭を取ってITU-TのHシリーズの仕様としてH.248が誕生しました。

結論から言えば、このH.248という言葉だけ覚えておけばいいわけですが、H.248ができたのが2005年頃(Megacoを廃止したRFC5125が2008年)のため、未だにMegacoという呼び方が生き残っています。

こうしてできたMegaco改めH.248ですが、基本的な仕様はH.248.1で規定され、その他の細々した仕様はH.248.xxと言ったサブ番号で定義されています。例として、NAPTトラバース機能はH.248.37で定義されています。

今後は基本的にH.248という言葉に統一するようにしますが、この連載名は親しみやすいように(!?)Megacoというタイトルを付けています。

なお、今後はもうMGCPは出てきません。標準でも何でもないものを扱うつもりはありません。

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

ゼロから学ぶSIP: 第02回 SIPが扱う「セッション」とは？

SIPとはセッションを開始するときに使うプロトコルです。ここでいうセッションとは、端的に言えば、通信元と通信先とその間を流れる情報(メディア)のセットのことです。RTP[RFC3350]でのセッションの定義に似ていますね。例えば、電話は発信者(通信元)と着信者(通信先)が音声というメディアを交換し合うセッションです。テレビは配信元(通信元)から視聴者(のテレビ)(通信先)へ映像と音声というメディアを流すセッションです。チャットは2人以上の通信者がテキスト(メディア)のやりとりをするセッションです。要は何か情報があってそれを送信する人、受信する人がいればそれがセッションなのです。何となくイメージできるでしょうか。なお、便宜上通信元と通信先という言い方をしていますが、メディアの流通は片方向とは限りませんので、通信元というのは最初に「通信を始めよう」と提案する人、通信先というのはその提案を受け取った人で、メディアを流す方向とは関係ない、という点に注意してください。

SIPが開始/操作するセッションと、RTPで定義されているセッションはちょっと違います。RTPでいうセッションは明確に、1つの通信元、1つの通信先、そしてその間に流れる単一のメディアと決まっています。つまり、映像と音声を流す場合は、それぞれが別のセッションになります。そして3者通話のように通信先が2つになる場合には、各々の通信先に対してセッションを張ります。一方、SIPが扱うセッションは、メディアが映像+音声のように複数ある場合でも、3者通話や複数地点から参加する電話会議のような2つ以上の通信先がある場合でも、1つのセッションとしてまとめて扱います。こうすることで、複数の接続先を関連付けて操作ができます。

SIPとは、上記のような通信者とメディアのセットを「セッション」という単位で識別できるようにし、それを操作するためのプロトコルだと言えます。

もう少し具体的な動作の中身を説明します。SIPはIPネットワ―ク上で動作するので、通信元、通信先はIPアドレスとポート番号が分かれば特定できます。またその間を流れるメディアは、メディアの種類(音声、映像、テキスト等)、コーデック名(G.711、H.246等)、転送レートなどを決定すればメディアを流せます。つまり、通信元と通信先が、お互いのIPアドレスとポート番号とその間に流すメディアに関する情報を共有できれば、通信を開始できます。RTPで通信をするときに必要な情報と同じですね。

つまり、SIPを使ってセッションを開始することとは、上記のような通信を開始するための情報を通信元と通信先とで共有することだと言えます。SIPはそれらの情報を伝達するルールを規定しているプロトコルです。

UEMCLIP(mU-law EMbedded Coder for Low-delay IP communication)

G.711との相互運用性を考慮しつつ、より高音質な通信にも利用できることを目的に作られた音声コーデック。ITU-TのG.711.1[RFC5391]に準拠している。G.711で扱える音域が300Hz～3.4kHzなのに対し、UEMCLIPでは最大で50Hz～7kHzという広い音域を扱うことができるため、より高音質な音声表現が可能となる。

概要

UEMCLIPの策定背景は、現在の電話の音声コーデックとして広く普及しているG.711との互換性を保ちつつ、より高音質な通信を可能にしたい、という思想に由来します。例えば高音質なコーデックと言えばG.722がありますが、G.711とG.722は互換性がありませんので、相互に運用しようとすると、それぞれをトランスコーダがいちいちエンコード/デコードする(=トランスコードする)必要があり、それがトランスコーダへの大きな負荷となります。一方UEMCLIPはG.711のデータを内包していますので、トランスコーダではそのデータを取り出すだけでG.711にしか対応していない端末とも通信できます。トランスコーダの負荷も小さくなります。

上記の仕組みはITU-TのG.711.1で提唱されていて、UEMCLIPはそれに準拠するようにNTT(と他5社)が提案したコーデックです。以下のサイトが詳しいのでそちらを参照してください。

UEMCLIP

UEMCLIP（ユーエムクリップ）とは"mU-law EMbedded Coder for Low-delay IP communication"の略称です。ITU-T G.711として広く利用されている電話音声符号化の標準方式を拡張し、高音質な広帯域音声での通信を可能にする符号化方式で、VoIP等の音声通信アプリケーションや多地点での音声会議用途を目的として、NTT研究所で開発された技術です。

• UEMCLIP概要仕様書(PDF)
• NTT研究開発この一年 2008年報 | 広帯域スケーラブル音声コーデックITU-T標準G.711.1
• ネットワーク技術 先端研 第11回 ITU-T国際標準に採用された高音質な音声符号化方式 ： モバイル＆コンバージェンス - TECH WORLD

UEMCLIPには複数のmodeが定義されていて、サポートするサンプリング周波数やビットストリームによって使い分けます。また、複数のmodeを動的に切り替えることもできます。サポートするmodeはSDPの中で指定します(下記の「使い方」参照)。

使い方

上記のページの「Download」のところに「RTP payload format」があるんですが、見事にリンク切れしています(2009/5/17現在)。以下のページにVersion06がありますのでそちらを参照してください。この仕様は定期的に更新されているようです。

• RTP payload format for mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec draft-ietf-avt-rtp-uemclip-06

UEMCLIPのパラメータ

パラメータ名	説明
メディアタイプ	audio
メディアサブタイプ	UEMCLIP
必須パラメータ
Rate	サンプリングレートは8000、16000のどちらかを指定します[MUST]。以下の表「UEMCLIPのmode一覧」にmode毎の指定可能サンプリング周波数を掲載しています。なお、a行のrtpmapで指定したサンプリング周波数よりも大きい周波数にしか対応していないmodeは指定できません。「Section 6.2.1 Mode specification」参照。
オプションパラメータ
ptime	20の倍数でなければなりません[MUST]。デフォルトは20(ms)です。
maxptime	フレーム長(20ms)の倍数(RFC4566の定義より)
mode	ビットストリームの形式を指定します。modeは0～5の数字で定義されていますが、2と5は将来のために予約されているので、実際には0,1,3,4が指定可能です。詳しくは以下の表「UEMCLIPのmode一覧」に示しています。「Section 2 Media Format Background」を参照。

UEMCLIPのmode一覧

mode	サンプリング周波数	G.711	低帯域拡張部	広帯域拡張部
0	8kHz/16kHz	○
1	8kHz/	○		○
2	将来32kHzに対応したときのために予約
3	8kHz/16kHz	○	○
4	16kHz	○	○	○
5	将来32kHzに対応したときのために予約

使用例

サンプリング周波数16000に対応する全mode(0, 1, 3, 4)をオファーする場合、modeは優先順位の高い順に並べる。

v=0
o=john 51050101 51050101 IN IP4 offhost.example.com
s=-
c=IN IP4 offhost.example.com
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=4,1,3,0

上記のオファーに対して、mode=0,1のみをセッション内で切り替えるアンサーを出す場合。なお、もしmode=0とした場合は、1に切り替えることはできません。

v=0
o=lena 549947322 549947322 IN IP4 anshost.example.org
s=-
c=IN IP4 anshost.example.org
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=1,0

オファーが、mode=4と0を許容できることをアンサー側に示したいが、動的に切り替えたくはない場合。この場合、アンサーにはUEMCLIPペイロードを1つだけ含めることが推奨されています(RECOMMENDED)

v=0
o=john 51050101 51050101 IN IP4 offhost.example.com
s=-
c=IN IP4 offhost.example.com
t=0 0
m=audio 5004 RTP/AVP 96 97
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=4
a=rtpmap:97 UEMCLIP/16000/1
a=fmtp:97 mode=1

通信用語を覚えよう: MG(Media Gateway)

Media Gateway(MG)とは、PSTN→IPの相互接続や、G.711→UEMCLIPのコーデック変換などを担うゲートウェイです。これによって、既存網からIP電話に電話しても、音声を適切に変換して通話できるようになります。

MGとは何か、ということをしっかり書いている日本語サイトが見つからなかったため、英語のWikipediaから全文引用します。

Wikipedia: Media gateway

原文

A Media gateway is a translation device or service that converts digital media streams between disparate telecommunications networks such as PSTN, SS7, Next Generation Networks (2G, 2.5G and 3G radio access networks) or PBX. Media gateways enable multimedia communications across Next Generation Networks over multiple transport protocols such as Asynchronous Transfer Mode (ATM) and Internet Protocol (IP).

Because the media gateway connects different types of networks, one of its main functions is to convert between different transmission and coding techniques (see also Transcode). Media streaming functions such as echo cancellation, DTMF, and tone sender are also located in the media gateway.

Media gateways are often controlled by a separate Media Gateway Controller which provides the call control and signaling functionality. Communication between media gateways and Call Agents is achieved by means of protocols such as MGCP or Megaco(H.248) or Session Initiation Protocol (SIP). Modern media gateways used with SIP are often stand-alone units with their own call and signaling control integrated and can function as independent, intelligent SIP end-points.

Voice over Internet Protocol (VoIP) media gateways perform the conversion between TDM voice to a media streaming protocol (usually Real Time Protocol, RTP), as well as a signaling protocol used in the VoIP system.

Mobile access Media Gateways connect the radio access networks of a public land mobile network PLMN to a Next Generation Core Network. 3GPP standards define the functionality of CS-MGW and IMS-MGW for UTRAN and GERAN based PLMNs.

拙訳

Media Gateway(MG)とは、異なる通信網の間に流れるデジタルメディアを変換する装置もしくはサービスのことです。ここでいう異なる通信網とは、PSTN、SS7、次世代ネットワーク(2G、2.5G、3G等の無線網を含む)、PBXなどのことです。MGは、(ATMとIPの相互通信のような)複数の転送プロトコルを用いる次世代ネットワークのマルチメディア通信を可能にします。
(訳注: ここでの「次世代ネットワーク(Next Generation Networks)」とは一般的な次世代ネットワークのことであり、NTTが謳うNGNを指しているわけではありません。)

MGは異なるタイプの網を接続するため、異なる伝送方式あるいは符号化方式の網同士でも変換できる機能を備えています。MGには、エコーキャンセラ、DTMF、トーン送信のようなメディアのストリーミングに関する機能も含まれています。

MGは一般に、Media Gateway Controller(MGC)という、MGとは機能的に分離された、呼制御機能、信号伝達機能を持った装置(機能)から操作されることが多いです。MGとCall Agent(CA)間の通信は、MGCPやMegaco(H.248)またはSIPのような通信プロトコルを用いて成立させます。最近のSIPと共に用いられるMGは、呼制御機能を持ったスタンドアロン装置で、SIPのエンドポイントとして独立的に機能することが多いです。

VoIPで用いられるMGは、TDMの音声をメディアストリーミング用プロトコル(RTP)へと変換します。共通線信号をVoIPシステムが扱う信号伝達プロトコルにするのと同じです。

移動体からアクセスするMGは、PLMNの無線網から次世代ネットワークへとを接続します。3GPP規格はPLMNsをベースにしたUTRANとGERAN向けのCS-MGWとIMS-MGWの機能を定義しています。
(訳注: 移動体には詳しくないので、この一文は何を言っているのかさっぱりです！)

謎の用語を解明しよう: Latch(とRelatch)

仕事で飛び交っている謎の言葉、Latch。アクセスライン側からエッジルータへパケットを投げるときに、「Latchする」みたいな使い方をしています。先輩に聞いてみましたが、言葉の定義がいまいちはっきりしません。「飛んできたパケットのソースIPアドレスを覚えること」というようなものだと説明は受けましたが、ルータやセキュリティの話には耳をふさいできた私には、とても理解できませんでした。。。:(

調べてみると、NAPT機能を実現するときに、MGCがMGに対して投げる命令の様です。

しかし情報がないですねー。ググってみると、LatchとはH.248.37で定義されているMegacoのipnapt packageのパラメータの様です。仕様書はITU-T H-series RecommendationsからPDF形式でダウンロードできます。

H.248.37の概要には以下の様に書いてあります。

H.248.37 Abstract
Gateway Control Protocol: IP NAPT Traversal Package

原文

Session Border Controllers (SBCs) are becoming an important part of the Internet infrastructure. Some of these Session Border Controllers are being split into Media Gateway Controller (MGC) and Media Gateway (MG) components. One important function of a SBC is to perform Network and Address and Port Translation (NAPT). H.248.37 allows the MGC to instruct a MG to latch to an address provided by an incoming Internet Protocol (IP) application data stream rather than the address provided by the call/bearer control. This enables the MG to open a pinhole for data flow.

拙訳

SBCはインターネットインフラにおいて重要部分になってきている。これらのSBCの中にはMGCとMG機能を分けているものがある。SBCの1つの大事な機能はNAPTを実現することである。H.248.37では、MGCがMGにIPアドレスを指定する方法として、Call Bearer Controlのものを提供するのではなく、流れてくるIPアプリケーションデータからIPアドレスをLatchできるようにすることを定義している。

いやー「Latchする」とかさらっと言われても分かりませんね :s 英語が分かる人はイメージが伝わるのでしょうか。CiscoのASR 1000のページに幾分説明が載っていました。

Latch and Relatch Support

When the LATCH value is set, the DBE ignores the addresses received in the RemoteDescriptor. Instead, the DBE uses the source address and source port from the incoming media streams to be the destination address and destination port of the outgoing streams.

要するにLatchというのは、MGがストリームの通信先を決める方法の1つで、普通は発信者が指定したアドレス+ポートをMGCがMGに設定するのだけど、MGCが「Latchしろ」と言った時はその設定を無視し、最初にパケットが飛んできたときに、そのパケットのソースアドレス+ポートを「Latchし」、通信先として動的に認識する方法のこと、らしいです(英語的に、Latch onto ～は「～を理解する」「手に入れる」という意味)。

もっと具体的に言うと、普通、発信者は自分がメディアを受け取りたいアドレス+ポートをINVITEのSDPのc行に載せ、それをMGCがMGにAddするときにRemoteDescriptorに記述するんだけど、そのときにipnapt/latch{ napt=LATCH,stream=1 }みたいに指定されると、RemoteDescriptorに記述された発信者のアドレス+ポート設定をMGは無視する。その代り、LocalDescriptorに記述されたアドレス+ポート(=MGがメディアを通したいアドレス+ポート)に最初に飛んできたパケットのソースアドレス+ポートを通信先として認識する、ということを「Latchする」というようです。文字だけで書くとややこしいですね。

上記は音声通話を開始するまでの流れを(かなり簡略化して)図示したものです。図中にオレンジの●が2つありますが、これが音声を流すポート番号です。この番号をお互いが認識しあえれば、音声通話を開始できます。Latch指定がされない場合、図中の数字の箇所では以下の動作をします。

1. 発信者から着信先に対してINVITEを出す(このときに発信者側の音声を送受信用のポート番号をSDPに載せる)
2. MGCからMGへ、発信者のポート番号を載せたAddを出す
3. MGがMG側の音声送受信用ポートを決定し、Add Replyを出す(ここでMGはRemoteとLocal両方のポート番号を決定)
4. Add Replyの情報を発信者に伝える。また、着信者側へも同様の操作を行うためにINVITEを転送する
5. MG側のポート番号が分かったため、音声を流せるようになる

一方Latch指定された場合は以下の様になります。

1. 発信者から着信先に対してINVITEを出す(このときに発信者側の音声を送受信用のポート番号をSDPに載せる)
2. MGCからMGへ、発信者のポート番号を載せたAdd(Latch指定付)を出す。
3. MGがMG側の音声送受信用ポートを決定しAdd Replyを出すが、Latch指定されているため、MGCが指定した発信者のポート番号を無視し、MG側音声送受信用ポートに入ってくるパケットを待つ
4. Add Replyの情報を発信者に伝える。また、着信者側へも同様の操作を行うためにINVITEを転送する
5. MG側のポート番号が分かったため、音声を流せるようになる
6. (図中にはないけど)MGは最初に飛んできたパケットのソースアドレスとポートを発信者のアドレス+ポート番号として認識し、通信できるようになる

また、RELATCHが指定された時は以下の様な動作をします。

1. 現在LatchされているIPアドレスとポート番号で通信を行う
2. 通信中に、発信者のソースポートが変わった場合、それを検出して新しいソースポート番号をRelatchし、通信先のポート番号として再設定する
3. Relatch後に、元のソースポート番号からパケットが飛んできても、そのパケットは不許可パケットとして弾く

ものすごい適当な説明ですが、これで伝わったでしょうか。。？実際にはLatch/Relatchを指定するときはgm/rsamでIPアドレスを絞ります(きっと)。そうしないとRELATCHを指定したときに流れパケットを通してしまいますから。

ゼロから学ぶSIP: 第01回 SIPの基本概要

SIPとはSession Initiation Protocol(セッション開始プロトコル)の略です。

SIPはIPネットワ―ク上で使われるプロトコルです。転送プロトコルにはUDPやTCPが使われるのが一般的です。通信時のセキュリティを気にする場合はTLSを使うこともあります。

SIPとは、通信するための条件を伝播する仕組みと、通信者同士で交渉し合う動作を定義したものと言えます。

SIPを使うと以下の様なことができます。

• 通信(セッション)を開始するための条件を揃えることができます。
• 通信条件を変更することができます。
• 通信を終了することができます。

しかし、SIPでは、実際に通信を行うための動作は定義されていません。そのためSIPは、RTPのような、他の通信をするためのプロトコルと一緒に使われることが一般的です。

SIPは他のプロトコルと一緒に使われますが、他のプロトコルを拡張はしませんし、SIP自体が何かのプロトコルに特化しているわけではありません。

SIPを使った情報のやりとりは、必要な情報をテキスト形式で記述して交換し合うことで進められます。やりとりするSIP情報を書いたテキストのことをSIPメッセ―ジと呼びます。SIPメッセ―ジはその内容によって、リクエスト(要求)とレスポンス(応答)の2種類に分類されます。

SIPは、通信元がリクエストを出し、通信先がそれに対するレスポンスを返す、という動作を繰り返すことで、通信するための条件を決定したり、通信条件の変更をしたりしていきます。リクエストを出し、レスポンスをもらうという動作1回分をトランザクションと言います。これはデータベースの世界で使われるトランザクションと大体同意です。

SIPは現在はRFC3261(和訳)で定義されています。