[epnetfan 座学編] [Internet Week 2005 報告会]


EPNetFan 2005 年度 座学編 第 XX 回 資料 Internet Week 2005 報告

[T11] インターネット電話の基礎と実験 メモ

話者は NTT の方, 始めは開発の方だったのだが, 最近は ISP などの 運用面に携わることが多いらしい.

VoIP な現場っぽいお話

前半は簡単な技術的話, 後半は運用的苦労 (?) 話



予備知識

SIP

読み方 : エスアイピー,

フルスペル : Session Initiation Protocol

VoIP を応用したインターネット電話などで用いられる, 通話制御プロトコル の一つ. 1999 年 3 月に発表された規格で, H.323 など同様のプロトコルより後 発のため, まだあまり普及は進んでいない. 転送機能や発信者番号通知機能 など, 同様のプロトコルと比べて公衆電話網に近い機能を備え, 接続にかか る時間も短くなっている. また, 各端末に割り当てられるアドレス形式が電 子メールアドレスの形式に近く, 将来的には共通化も可能とされている.

インターネットと電話網の関係

NTT や KDDI の既存電話網はぼちぼち IP 化されつつあるらしい. でもまだ交換しきってはいないみたい.

三角形の上に横線を引いてあるのは電話機のマーク. 縦長四角の中にばってんが書いてあるのは交換機のマーク.

VoIP は Inernet 網だけを利用することもあるが, 自分 ⇒ Internet 網 ⇒ 電話網 ⇒ 相手のように, 昔のモデムを 利用したネットワーク接続とは逆向きの接続を行っている.

技術的観点での比較

VoIP は1つのネットワーク内で全ての処理を行う. 今までは, 電話回線網で音声を運ぶ以外に, 電話番号は他の 線から運んでいた.

VoIP を実現する技術的要素

パート1 〜 パート5 で様々な技術が使われている. 以降ではこれらのここの要素に関する解説を行う. 全てが VoIP を実現するための技術なので迷ったら ここに戻ってきましょう.

関連イベント

技術が出来るだけでなく, それを生かした商品が出ないと, 技術は生かされない.

Windows XP の Windows Messanger が SIP 対応で, そのうち 2000/98/Me の MSN Messenger ver4.x から SIP 対応 のため, ユーザ側のアプリケーションとしては揃う. (ネットミーティングに使われる).

その後, YAMAHA RT60w ルータ が SIP 対応する. (ちなみにこのルータは無線搭載, IPv6 にも対応しているという優れもの(?) だったらしい).

XP + RT6060w の2つの装置が揃ったことで, VoIP の基盤が整った.

その後, BB phone サービスが始まり, 他の ISP が対応していって どんどん広まった.

パート 1

呼制御プロトコル

昔の電話網では, 電話網の他に制御網と STPがあり, そちらで空き回線が あるかどうかを制御していた.

一昔前は, VoIP は電話番号管理サーバを置いてそいつに制御させてた.

SIP を使った簡単な通話

相手の IP が分かっててネットワークに接続されている時は, あいての IP へ向かって呼ぶだけで会話できちゃう.

今は当たり前(?) かもしれないことがその時にはかなり衝撃的な出来事.

デモ

実際に通信した様子を EtherReal で見てみて様子を見せてくれた. データの中身は全部文字列だよ, といってた.

INVITE ダンプ

プロキシ

INVITE というパケットを相手に送ると相手の PC は鳴る.

しかし, 実際は相手の IP アドレス分かんない.

VoIP での相手先の識別 (すなわち電話番号に相当) には URI を 用いる. (URI ≒ URL, 最新の RFC では URL では無くて URI になってる).

相手がわからない時には, SIP サーバを使う. (資料の図の上にあるサーバ).

REGISTER メッセージをサーバに送っておいて登録する. >From の URI と自分の IP を送る.

このサーバに別の人が INVITE を送る. 相手の IP を知らなくても, 相手の URI さえ知っていれば良く, サーバに送ると先ほど REGISTER された内容から IP アドレスをもらい, それを返す. そこまで来たら SIP サーバは用済み.

代表的なヘッダ

メッセージフォーマット

メールとよく似てる. SIP ヘッダの後に空行をいれる. その下に 本文が書き込まれる.

一行目が "SIP" という文字列で始まってればレスポンス. そうでなければリクエストを指す.

用語

ダイアログの中にいくつかのセッションが含まれる. 1つのダイアログの中で何度か INVITE を送ることも可能.

INVITE + 180 RINGING + 200 OK で1つのトランザクション. BYE + 200 OK で 1 つのトランザクション.

Caller と Callee のどちらかがかならずサーバになるのではなく. 始めにリクエストを送る方がクライアント, もらう方がサーバと なるため, この図では始めのと最後とのトランザクションでサーバと クライアントが入れ替わっている.

1xx プロビジョナルレスポンス
まだ継続している事を指し, 1つのトランザクションで何度でも 返せる.
2 〜 5xx ファイナルレスポンス
これでトランザクションが終了することを指す. 200 番代は正常終了. 300 以上はエラー終了.

REGISTER シーケンス

一度目の REGISTER の返事が返ってきた後に, 本当の レスポンスを返す. (??)

普通のインターネット上の技術を用いている. (他にもいえるが, SIP が広まったのはインターネット上で汎用的に 使われる技術と同じような技術を用いているため).

認証方式

PAP
CHAP

どっちも一長一短.

Digest 認証の仕組み

ワンコールシーケンス

INVITE

Cancel

電話をかけても相手が出ないので, 送信側が受話器を置いた際に 送られるメッセージ.

そうすると, 最後に 487 というファイナルレスポンスが返り, 通信が終了する.

Cancel (親子電話)

ルーティング

複数の SIP サーバを通って相手と通信を開始, 終了しようと する際には, それらの INVITE や BYE メッセージおよびその 返事 (200 OK など), は端末同士で直接行うのではなく, ちゃんとその INVITE が通った道筋と同じルートを通って 返って欲しい.

STRICT ROUTING (caller 側から)

ルーティング情報は TCP ヘッダや UDP ヘッダ内に無いので, SIP ヘッダに書き込む. (そうでないとレスポンスを返す際, どれが正しいルートなのか分からない).

書くのには 2 種類あり, Via ヘッダ, RecordRoute ヘッダがある

返る際には, Via ヘッダは削除しながら返す.

STRICT ROUTING (callee 側から)

INVOKE の SIP ヘッダにルーティング情報が分かっているので, そこから BYE ヘッダを返す際のルーティング情報を作成する.

パート 2

通信が確立し, 音声情報が行き交いだした段階で, SIP の役割は 一旦休止する. 終わる時にまた BYE などを送るが, それまでは 全く何もしない. (たまに生きてるか確認するためにメッセージ送るけど).

予備知識

RTP

読み方 : アールティーピー,

フルスペル : Real-time Transport Protocol

音声や映像をストリーミング再生するための伝送プロトコル。パケットロス 対策や伝送時間保証などは行われていないUDPタイプのプロトコルで、通常 はRTCPによる通信状態レポートとセットで用いられる。RTCPによって実効帯 域幅や遅延時間などをサーバに送出し、サーバは報告された通信状態に合わ せてRTPで送信するデータの品質を調整して送信するという形を取る。1996 年に提唱されたプロトコルで、現在はQuickTimeやRealPlayerがRTPに対応し ている。

音声伝送

RTP パケットダンプ

RTP

RTCP

遅延などを知ることができる.

現在あまり使われていないらしい. (実装されて無いという問題がある. あと, これによって圧縮 codec 等変更できるが, 実際に電話網と 通信する時はある codec を利用せねばならず, わざわざこれをもちいて 変更を行うことが無いため).

サンプリング

電話は音質を落とすことで通信速度を高速化

一様量子化と圧伸量子化

非線形量子化を行うことで, 振幅が小さいものでもちゃんと量子化できる (?)

符号の種類

真ん中を 0 とするか 128 にするか 256 にするか…?

パート 3

NAT やファイアウォールを越えてどんなふうに通信すればよいのか?

NAT と SIP の問題

REGISTER する PC がプライベート内にあると, 登録される IP は 当然プライベート IP なので, INVITE するとあて先不明になってしまう.

NAT3

プロキシーを使う方法
ALG/SBC が SIP を書き換えてくれる方法. 最近良く使われる手法. ネットワーク自体は変更しなくて済む.
STUN サーバ

資料には無いが, STUN サーバというものを利用する方法もある. STUN サーバに問い合わせると, 「自分の IP: ポートは世界からどう見えますか?」 の問いに対する答えがもらえる. なので, その IP とポートを SIP サーバに 送ると良い.

ただし, Cone NAT には有効だが, Symmetric NAT には無効になってしまう. Cone NAT はどの相手に対してもポート番号が有効なので大丈夫だが, Symmetric NAT は相手毎にポート番号が変わるため, STUN サーバと SIP サーバで別ポートになってしまう.

結局, 現状として決定的な解決が難しい. とりあえずはプロキシーを 使う方法が一番楽.

ALG SBC による NAT 越え

Mobile IP による NAT 越え

SIP に NAT を越えさせるのではなく, 別のプロトコルに越えさせる手法. MN (Mobile Note) は Mobile IP を持てば, 1つの IP をもったまま 別のプロバイダや NAT 内にも入り込める.

トンネリングプロトコル

FA: Foreign Agent を使うことで, 一時的に特別なルーティングテーブルを 作成, 転送してもらう.

システムフレームワーク CoA モード

Proxy MIP

結局のところプライベート IP 空間からでもグローバルアドレスとして 通信が可能.

品質、信頼性

音質劣化の原因

音響問題

マイクとスピーカが近いことが原因. 相手方が大変.

セキュリティ問題

SIP 内にはセキュリティ対応してない.

INVITE パケットを送ったままにしておくと, ベルが鳴り続けさせることが 可能. 嫌がらせに最適…???

簡単な作りなために広まりつつあるが, 一方でこれらのフォローは まだ. 問題が起こってから対応というインターネット世界のいつもの 作戦.

IPPBX と SIP の違い

IPPBX は SIP のでかいもの

パッと見のシーケンスは同じ.

SIP は端末同士でダイアログを構成するが, IPPBX はそれぞれの端末同士が IPCX とダイアログを構成する. すなわち 2 つのダイアログは分断されている.

コールピックアップ

音声サーバアプリ

SIP を使ってみたい時は Windows Messanger 4.x を使ってみると良い. (5.x はバグがあるらしい...)

Linux で動く SIP サーバもあるらしい.

資料巻末の参考情報の演者の URL を探るとそういうソフトもあるらしい. フリーで作っている SIP クライアントとサーバもあるらしい.

[epnetfan 座学編] [Internet Week 2005 報告会]


Copyright © 2005 EPNetFan
Last Updated: 2006/01/21, Since: 2006/01/21