FreeSWITCHをひかり電話の外線通話に自動応答させるめどがたった…かもしれない

 「FreeSWITCHをひかり電話の外線通話に自動応答させることができない」、「その2」、と、FreeSWITCHをひかり電話の外線通話に自動応答させる努力を続けてきた。これも元をただせば「ケチケチ携帯大作戦」のためである。金を倹約するためにここまで頑張ってしまえる自分の貧乏人根性には自分でも少し感心してしまう。

さて、ひかり電話とはNTT東西がそのフレッツ光インターネット接続サービス契約者に、オプションで提供しているVoIPサービスである。050で始まる番号しか受給できない他のVoIPサービスプロバイダと違い、固定電話番号をそのまま引き継げ、かつ費用が安価(月515円)であるところが一般に見える利点であるが、このサービスがSIP標準に準拠していることこそが、ある程度技術的素養のある人にはいろいろ遊べる可能性を開いてくれるのでオイシイのであった。

具体的には、NTT東西から提供されるVoIPアダプタが(一部を除いて)SIPサーバとしてアクセスできるので、それにソフトウェアSIPフォンを子機として登録してしまえるのである。(この「SIPサーバ」という呼び方もSIPの観点からは正確ではないのだが、一般的なクライアント/サーバの区別にならって本稿ではそのように呼ぶ。)ありがちな応用は、iPhoneのようなスマートフォンからホームLANにVPN接続し、iPhoneのSIPクライアントソフトからVoIPアダプタに登録することで、外出先からも自宅の固定電話番号宛の電話を受信および送信すること。自分もそれをやりたいが、自宅固定番号は父と共有しているので、もう少し複雑なことをしたいと考えている。具体的には、自動応答システムで、発信者の入力によって子機(内線)の鳴り分けをしたい。

ところで、SIPと一言でいうが、SIPプロトコルは呼の制御のみ担当し、音声データの通信はRTPという別のプロトコルで行われる。自分がNTT西日本から貸与されているVoIPアダプタAD-200SEの挙動をWiresharkを使って観察すると、内線間通話と、外線着信の場合で違いがあることがわかる。内線間の場合は、エンドポイント間で直接RTP通信が起きるようにしている。ただ、それは双方ソフトフォンである場合で、どちらかがAD-200SEに接続されたアナログ電話の場合は、当然AD-200SEとのRTP通信が起こる。外線着信の場合はどうかというと、子機(ソフトフォンだとして)が上流のNTT局内のサーバと直接通信するのではなく、AD-200SEと、子機との間でRTP通信が起きる。

自分としては正しいと思う設定をFreeSWITCH(以下単に"FS")にし、AD-200SEに子機として登録した後、固定電話番号にかけてみると、FSは期待通り自動的に応答するのだが、呼び出し側に音声が聞こえる前に通話が勝手に切られてしまう。パケットのやりとりを眺めると、SIPでAD-200SEからINVITEが来て、それにFSはOKを返し、さらにそれに対してAD-200SEはACKを返している。わからないのは、その直後にAD-200SEがBYEを送って通話を終了してしまうことだ。RTPパケットについては、SIPでOKを送った後、FSからAD-200SEに流れ始めるのだが、逆方向の通信が起こらない。詳しくはパケット交換のログをご覧頂きたい。192.168.11.250がAD-200SEに割り振ったIPアドレスで、192.168.11.11がFSを走らせているPCのそれである。

AD-200SEからFSへのRTPパケットが流れないことで最初に疑ったのがFSを走らせているPCのファイアウォールである。しかしこれはファイアウォールを切っても結果が全く変わらないことで否定された。

次に疑ったのがFSが送信するRTPパケットが何らかの理由で問題である可能性。実はこれは今でも完全には否定されていない。他の子機から内線電話でFSを呼び出すときちんと応答する。アナログ子機からの通話であれば、RTP通信はFSとAD-200SE間で起こるわけだから、少なくともAD-200SEはFSの吐くRTPパケットを問題なく受け入れているということになる。また、Wiresharkで素人なりに眺めた範囲では、例えばAsteriskの吐くRTPパケットと違いが見つけられなかった。

その次に疑ったのがタイムアウト。AD-200SE自身はタイムアウトを起こしていないが、上流で起こしているのではないか、と。それならそれで、BYEメッセージにそうと分かる理由が含められているべきだが、残念ながらNTTのサーバはそこまで親切ではないということなのかもしれない。AsteriskWin32のレスポンスとFSのレスポンスを比べると、後者の方が明らかに遅いので、一時はこれが理由かのように思われた。しかし、他のSIPソフトフォンで、FSよりもレスポンスが遅いものでも、それに対する呼がFSの場合のように切られてしまわないことに気づいて、これの可能性も否定された。

最後に疑ったのが、FSが出すSIPメッセージ、特にINVITEに対するOKがまずいのではないか、と。ACKを返しているので、AD-200SE自身は明らかに問題なく受け入れてる。しかし、AD-200SEはFSからのOKを元に上流のNTTの局内のサーバにOKを送っているはずで、これが何らかの理由で気に入られず、一方的に呼がキャンセルされてしまうのではないか、と。

掲示板に投稿してみたりしたが、全くレスポンスがなく、試行錯誤するしか手がない。最初は、Remote-Party-ID:というヘッダがいかにも怪しいと思った。最新版のFSでこれを除く手段はわからなかった(FreeSWITCH-usersというMLで質問してみたが、返事はない)。が、たまたま古い1.0.4のWindows用バイナリも提供されており、この版ではこのヘッダをつけない。この版でテストしてみたが結果は変わらなかった。このヘッダが問題なのではなさそうだ。

今疑っているのは、以下のように、To:ヘッダでsip:スキームではなく、tel:スキームを使っているところ。

To: <tel:ABCDEFGHIJ;phone-context=192.168.11.250>;tag=Xa59ZeNtHmX9e

これをsip:スキームに変える方法がまだ分からない。MLで質問しても、また無視されている。このメッセージだけ書き換えるプロクシを使ってテストしたかったのだが、そうそう好都合なものは見つからない。そのようなものは、こういった非常に特殊な状況でしか存在意義がない。あるものは、当然もっと高機能なものになる。

そこでやけくそでAsteriskWin32をプロクシのように使ってみることにした。つまり、それをAD-200SEの子機として登録、FSをAsterikWin32の子機として登録、そしてAsteriskWin32は単純にかかってきた呼を自動的にFSに繋ぐように設定。これならばAD-200SEが見るOKメッセージは「AsterikWin32謹製」で、To:ヘッダもtel:スキームではなくsip:スキームを使っているはずである。

試してみると、外線からの呼にFSは期待通りの自動応答した。もちろん、これでわかるのは、どうやらFSの出すSIPメッセージが問題の根源であるようだ、ということだけで、具体的にどこが問題だということまではわからない。ただ、そこまでの推理は当たっていたということのようで、喜ばしい。もっとも、FS自身でその挙動を変えることができなかったら意味がないのだが…。

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

コメントを残す

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

WordPress.com ロゴ

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

Twitter 画像

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

Facebook の写真

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

Google+ フォト

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

%s と連携中