ひかり電話の子機持ち出し~コーデック編

ひかり電話の子機持ち出し~構成編その1」、「その2」の続き。

構成編その1」で、ひかり電話の子機持ち出しを考える上で、必要になる通信帯域を節約するため、VPN使用と、PCMUコーデックの使用は避けるのが望ましい、と述べた。その2」では右図のようにセットアップすることで、VPN接続せずともある程度安全にひかり電話の子機持ち出しが可能であることを示した。

今回はコーデック編。もうひとつの課題であった、PCMUコーデックの使用の回避をいかにして達成するかが主題となる。以下、「その2」で示したセットアップを前提に話を進める。なお、PBXesを介したGoogle TalkやGizmo5の利用については、本題ではないので今回は触れない。

PCMUコーデックの使用の回避といっても完全に回避できるわけではない。ひかり電話の貸与するVoIPアダプタうちの場合はAD-200SE)とFreeSWITCHとの交信部分までは、PCMUを使わざるをえない。これはひかり電話の仕様であるからなんともしようがない(うまいっ)。とはいえ、ここまでは十分高速なネットワーク上で起こるので、そもそもPCMU使用は問題ではない。問題なのはここから先である。

PCMU以外のコーデックをX10
miniのSipdroidが使えるようにするためには、通信パスのどこかでトランスコーディングが行われる必要がある。それをさせるのは、
FreeSWITCHとPBXesが可能性としては考えられる。

これらを比較してみよう。FreeSWITCHでトランスコーディングする場合、ホームLAN内以外のRTPによるメディア通信が、全て使用帯域の少ないコーデックで行える。さらに、メディア通信についてはPBXesをバイパスする(飛ばす)ようにすることもできるはずで(右図参照)、もしそのようにしたいのなら自動的にFreeSWITCHが唯一のトランスコーダーの選択肢になる。ただし、トランスコーディングを行うPCにはその間負荷が高まるので、そのPCの使い方によってはそれが不都合かもしれない。


一方PBXesでトランスコードさせる場合(右図)、FreeSWITCHとPBXes間のRTP通信はPCMUで行われるため、より使用帯域の少ないコーデックを使う場合に比べて、遅延等が生じる可能性が潜在的にはある(実際あるかどうかは全く別問題)。自宅PCにトランスコーディングの負担が生じないのは利点だが、PBXesのサーバーのパフォーマンスが十分高くなければ結局遅延などが生じる可能性がある。

詰まるところ、FreeSWITCHとPBXes間の通信が十分に高速であると仮定するなら、自宅PCで走るFreeSWITCHと、PBXesのサーバのどちらがより高速にトランスコーディングできるかがこの選択の決め手になる。

この答えを出す前に、PCMUからトランスコーディングをするときのターゲットのコーデックは何がよいか考えよう。X10
miniではSipdroidを使うのだとすると、Sipdroidがサポートするコーデックから選ばないといけない。Sipdroidがサポートする
コーデックを使用帯域の小さいものから並べると、speex (11kbps), GSM (13kbs), BV16 (16kbps), PCMU
(64kbps), PCMA (64kbps), G722 HD Voice (64kbps)となる。この順に検討していくことになる。

試してみると、PBXesはBV16には対応していないようである。そうすると、PCMUより使用帯域が小さくなければ意味がないので、事実上speex (11kbps)とGSM (13kbs)の2つしか選択肢がないことになる。 その他にも有望そうなコーデックは存在するし、最近発表されたspeexの開発者によるCode2などは非常に期待が持てるが、当然ながらサーバとクライアントの双方が対応しているコーデックでないと使えないので、いたしかたない。

実際にトランスコーディングのテストしてみた。どうやってFreeSWITCHとPBXesのそれぞれでトランスコーディングを起こすようにしたのかについてはまた後日。また、今のところ117番の時報サービスに電話をかける、つまりoutboundのテストのみ。最終的にX10 miniが外出先でデータ通信に使うのはb-mobileSIMによるものなので、実際にそれを利用しつつX10 miniからSipdroidを使って発信する。

FreeSWITCHは、いずれ自分のデスクトップPCを入手した暁にはそれに交代させるつもりではあるが、現時点では父の富士通 FMV-BIBLO NB18C/T(モバイルPentium4-M 1.8GHz、メモリ768MB)で走らせている。このPCにはPCMUからspeexへのトランスコーディングは全く手に負えないようで、CPU使用率はずっと100%を示す。当然ながらかけた側は断片的な音しか聞こえない。これは、発信をホームLAN内のPC上のソフトSIPフォンからかけても同じであり、トランスコーディングがボトルネックになっていることがわかる。GSMにすると、トランスコーディング中のCPU使用率は60-80%程度に落ち、ソフトSIPフォンからかけた場合ならたまに一瞬音が途切れる程度で、会話は成立する。しかし残念ながら、b-mobileSIMを使ってインターネット接続しているX10 miniからSipdroidを使って発信すると、音声は途切れ途切れとなり、実用にはならない。

なお、実はメディア通信のバイパスは成功していない。現在原因を調査中。なので上の実験結果は、メディア通信についてもPBXesを経由している状態でのもの。

次に、PBXesにトランスコーディングさせると、speex、GSMとも、ときどき一瞬音が切れたりするが、一昔前の携帯/PHS通話でもそうであった程度で、実用レベル。GSMよりspeexの方が若干途切れが少ないよいように思えた。また、発信操作をしてから実際に通話が始まるまで長いと数秒の遅れがある。これは一つには、SipdroidがPBXesに登録しなおしたりするから。通話が始まったときには、その遅れを取り戻すためか、早送り再生のように聞こえる。

FreeSWITCHでのトランスコーディングがうまくいかなかった段階で、この長々と引っ張ってきたケチケチ携帯大作戦」も失敗に終わるように思われて暗澹たる気分となったが、PBXesが自分が期待していたい以上の働きをしてくれるので救われた形だ。もちろん、b-mobileSIMのデータ通信速度は波があるだろうし、これからもテストは続けていくつもりだが、ひとまずそこそこ使えそうだとわかって、大変喜ばしい。うれしくって、実はさっきから何度も時報サービスに電話かけているのだ。

広告
カテゴリー: Computers and Internet パーマリンク

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中