macでひかり電話の発着信をするのにZoiper3を使っていたのだが、Retina対応すらしてないしいい加減アップデートないのかな……と思ってそのサイトを訪れたところ、なんといつの間にか新バージョンが、それも4も飛んで既に5になっていたので早速インストールしてみた。
以前もセットアップに手こずったのだが、今回もまたうまくいくのに1時間以上要してしまったのでとりあえずメモを書き置いておく。
環境
まず、手元の環境は以下の通り。
- ひかり電話ルーター(hgw) RT-500KI (05.00.0010) : NTT西 (契約はドコモ光)
- OS X 10.11.6 (El Capitan)
- Zoiper5 (v5.2)
なお、hgw側の設定は他サイトで色々情報があると思うのでここでは省略する。(今回は既存のものを流用したため触っていない)
Macをひかり電話の子機にしちゃおう!〜ソフトフォン「Zoiper」を試す!〜
なお、設定に手こずったのだが従来バージョン(v3)から設定は引き継がれないが、mac版ではv5からは配布がdmgではなくpkgに変わってい、またv3とは別にインストールされたため共存が可能である。
あとCommunityEdition(無料版)は起動時に毎回アップグレード広告が出てくるみたい。かなりうざい。
初回設定
実はここからつまずいてたのだが……いちからやり直して設定し直すのも面倒なのでCloco株式会社が公開している操作マニュアルのスクショを流用させて頂く1。
上の欄にuser@host、下の欄にパスワードを入力する。たとえば以下のような内線設定でhgwのIPアドレスが192.168.1.1の場合、「4@192.168.1.1」「0123456」を入力。
ログインサーバーは自動的に「192.168.1.1」のように入力されているはずなのでそのままNext、入ってなかったら入力
ひかり電話ルーたーはプロクシ認証が必須のようなのでここではOptional~~の左にあるチェックボックスに✓を入れ、上の欄にユーザー名を入れる。さっきの設定であれば「0004」。下はからのままでいい。(最初何故か上下逆に入力してしまってエラー出て焦った)
ここまでの設定が有っていればSIP UDPが検出されて自動選択されるはず。されないようなら戻って見直し。
次の画面からはスピーカーとマイクの設定が出来ます。
まずは電話をかけてみる
さて、初期設定が終わるとこんな画面。
ダイヤルパッドから発信できるはずなので携帯かどっかにかけてみましょう。
もしここで発信できたのであればお疲れ様です。
この先は必要ないでしょう。着信も受けれるか試しておきましょう。
…
私はダメでした。
発信中しようとするものの……すぐ切れる。ログを見ると488が返ってきてることが分かります。
NTT東のひかり電話インタフェースの文書が見つかったのですがこれによると488はaudioメディアが未設定の際などに返されることがあるようです。
……なんでや……技術的な話は後に書きます。
とりあえずAudioコーデックが問題のようなのでそれを変えればいいようです。
ひかり電話ルーターはPCMU(ITU G.711)というコーデックを扱えます。Zoiper5はデフォルトでは利用できるすべてのコーデックが選択されている(opusの優先が高い)ようですがそれだとPCMUが利用可能な候補として送られない(バグか?)ので、PCMUに固定してやればいようです。
- 歯車のアイコンから設定画面を開く
- Accountsを選びアカウント設定を開く
- アカウントを選択
- Advancedをクリック
- Audio codecs までスクロールしてG.711以外をすべて左ペインに動かす
- 左上の❌で設定画面を閉じる(保存するか聞かれるのでYES)
これで再度発信操作をすると正常に発信出来るはずである。(少なくとも自分はそうだった)
技術的な話
この問題を調べるのにWiresharkで通信をキャプチャしてみた。ここで用いてるSIPはUDPで平文を喋っているためパケットキャプチャするだけでリクエストも通話も読めちゃうわけか……()
正常時の流れ
さて、SIPクライアントは発信時にSIPサーバーにINVITE
リクエストを送る。
1 |
INVITE sip:<相手電話番号>@192.168.1.1;transport=UDP SIP/2.0 |
ヘッダーは省略するとしてbodyに扱えるcodecを含めてリクエストするよう。
例えば、うまくいってたv3の場合は以下のよう。
1 2 3 4 5 6 7 8 9 10 11 12 |
v=0 o=Z 0 0 IN IP4 192.168.1.123 s=Z c=IN IP4 192.168.1.123 t=0 0 m=audio 8000 RTP/AVP 3 110 8 0 98 101 a=rtpmap:110 speex/8000 a=rtpmap:98 iLBC/8000 a=fmtp:98 mode=20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv |
6行目以降で使用可能なcodecを送りつけている模様。このうち101のa=rtpmap:101 telephone-event/8000
はPCME/8000のよう。
サーバーは
1 |
SIP/2.0 100 Trying |
と応答し、問題なければ
1 |
SIP/2.0 183 Session Progress |
も返す。
この183の応答本文に以下のように利用するcodecを含める。
1 2 3 4 5 6 7 8 9 |
v=0 o=- 100107 100107 IN IP4 192.168.1.1 s=- c=IN IP4 192.168.1.1 t=0 0 m=audio 5020 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=ptime:20 a=sendrecv |
ここまでが発信時の一連の流れ。(このあと SIP/2.0 180 Ringing
などが続く)
ダメだったとき
上記と同様にINVITE
リクエストを飛ばす。
(たぶん)初期設定のままでINVITE
の本文は以下のようだった。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
v=0 o=Z 0 0 IN IP4 192.168.1.123 s=Z c=IN IP4 192.168.1.123 t=0 0 m=audio 8000 RTP/AVP 106 9 3 111 0 8 97 110 112 98 101 100 99 102 a=rtpmap:106 opus/48000/2 a=fmtp:106 minptime=20; cbr=1; maxaveragebitrate=40000; useinbandfec=1 a=rtpmap:111 speex/16000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=20 a=rtpmap:110 speex/8000 a=rtpmap:112 speex/32000 a=rtpmap:98 telephone-event/48000 a=fmtp:98 0-16 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:100 telephone-event/16000 a=fmtp:100 0-16 a=rtpmap:99 telephone-event/32000 a=fmtp:99 0-16 a=rtpmap:102 G726-32/8000 a=sendrecv |
基本的に変わらないはずだけれど対応コーデックが増えたのでとりあえず多い。
最初「PCMUないじゃん」と思ってしまっていたがよく見なくても先ほどと同じtelephone-event/8000
があった。
これを受け取ったサーバーはSIP/2.0 100 Trying
を返すが……すぐに
1 |
SIP/2.0 488 Not Acceptable Here |
を返す。出た、488。
変更後
基本的には初回と変わらない。PCMUと、ついでにopusを1つだけ追加してみた場合のINVITE
のリクエストペイロードは以下のようになった。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
v=0 o=Z 0 0 IN IP4 192.168.1.123 s=Z c=IN IP4 192.168.1.123 t=0 0 m=audio 8000 RTP/AVP 106 8 98 101 0 a=rtpmap:106 opus/48000/2 a=fmtp:106 maxplaybackrate=8000; sprop-maxcapturerate=8000; minptime=20; cbr=1; maxaveragebitrate=15000; useinbandfec=1 a=rtpmap:98 telephone-event/48000 a=fmtp:98 0-16 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv |
これに対しサーバーは
1 |
a=rtpmap:0 PCMU/8000 |
で応答した。以下違いは見られない。
どのcodecが問題、というわけではない
ソフト設計上の問題なのかよくわからないが、どうもhgwのソフトに問題がありそうに思われる。というのも無作為に7つのコーデック(ただしG.711 mu-law = PCMU/8000は含む)を選択(下記画像)して試したところPCMU/8000以外のコーデックの組み合わせに関係なく発信が行えたが、8つ以上のコーデックを選択すると順番、組み合わせを問わず488エラーになる現象が確認できた。
もちろんG.711 mu-lawの選択を外すと当然488になる。
ところでAGEPhoneはいくつかの対応コーデックの内ひかり電話自動設定にはPEMUのみが利用可能になるよう設定されていたが、そういうことなのだろうか。
以上のことより、hgwでSIPクライアントを使用する際は(サーバー(hgw)側が)使用可能なコーデックに絞ってリクエストを送るべきのようである。
追伸
デフォルトではSTUNが使用する設定になっているかもしれないけどひかり電話でこれは普通どう考えてもいらないはずなのでDon’t use STUNにしておこう。
参考資料
ひかり電話インタフェース仕様: 投稿時には存在をしらなかったので想像で試していた部分があるが、こちらを対照することでより仕様にそった設定と理解ができそう
-
CommunityEditionはアカウントが1つまでしか設定できない
クソ仕様 ↩