これまでは Fig.1 にあるように、スマホのアクセスはRaspberry PiとのL3-VPNを経由して行っていました。内線環境としてはRaspberry Pi上ではSIPサーバとしてAsteriskが起動しています。

Fig.1

セキュアで、発呼・着呼のレスポンスや通話の音質にも不満はなく利用できています。またofficeから外出した時、外出先からoffice内に戻った時などでWiFi回線と3G/4G回線でネットワーク環境が切り替わるのですが、VPN経由のためネットワーク環境の変化の影響もなく利便性は高いです。
WiFi・3G/4G回線の切り替えがVPNアプリ側の恩恵を受けてシームレスに利用できます。

バッテリーの減り

数年以上これで運用していたのですが一つだけ困ったところがありました。そこが今回のタイトルにつながるところなのですが、スマホのバッテリーが持たないのです。

どのくらい持たないかというと、朝一に100%の充電量でも昼には70%台で夕方には20%台といった感じです。しかも発着信無しの待ち受けのみ、アプリ操作も時間と充電量の確認などでトータル10分ぐらいでほぼ無しです。

25%/4hぐらいで充電量が減っていっているので、無充電のバッテリー運用だと満充電しても16時間程度しか待ち受けできない感じです。実運用では充電のチャンスがあるのでここまでにはならないのですが。

バックグラウンドにいても着信のためアプリが動作しバッテリーの大食いが発生しているわけですが、pushで着信の待ち受けができれば望ましいことです。

push着信のための変更

今回は内線のpush着信を可能にすべくAsterisk周りとネットワーク周りを変更していきます。どのように変更していくかというとFig.2、Fig.3のようになります。

Fig.2 SessionTalk(Pro)がバックグラウンドにある

Fig.3 SessionTalk(Pro)がフォアグラウンドにある

SIPクライアントの置き換え

スマホ側のアプリがpush対応していないのが要因なのでまずはpush対応しているSIPクライアントと置き換えます。push対応のSIPクライアントとしては Zoiper や acrobits softphone などいくつかかありますが今回は SessionTalk無料版をapp内課金(push着信有効化)したSessionTalk(Pro) を利用します。最初からpush着信が有効な有料のSessionTalk Proでも大丈夫です。いくつか比較しましたが、内線のpush着信対応に当たりmust条件として CallKitでの着信時にFromヘッダの表示名を表示できる ことがありました。条件に合致するものが SessionTalk(Pro) の一択となりました。

今回利用するSessionTalk(Pro)ですがアプリがフォアグラウンドにある時にはFig.3に示すようにAsterisk@VPSに対してアプリが直接Registerするのですが、アプリがバックグラウンドに移るタイミングでSissionTalk LtdのSIP ProxyサーバがAsterisk@VPSに対してRegisterしています。SessionTalkに限らずpush対応SIPクライアントでpush着信を利用する場合はこのような形態になるかと思います。

VPSの用意

内線SIPサーバはこれまで通りAsterisk@Raspberry Piで動作しているのですが、Fig.2、Fig.3で示されるようにsmartphoneの接続先としてglobal上にあるAsterisk@VPSを新規に用意しています。

これはSessionTalkの接続先サーバにドメイン名を用いて設定したときに、SessionTalkがバックグラウンド動作に移行するときにSessionTalkがsmartphoneのデフォルトDNSとgoogle public DNS(8.8.8.8)の両方で名前解決を行い両方のDNS正引き結果IPが一致しないと SessionTalkはRegisterしない≒push着信できないになってしまいます。3G/4G回線経由だとHGWとsmartphoneのglobal-IPが相違するのでpush待ち受けに入るのですが、 WiFi経由だとHGW内でのprivate-IPがsmartphoneに割当てられgoogle public DNSでの正引き結果がHGWのglobal-IPとなってしまいDNS正引きのIPが一致しないためSessionTalkがエラーとしRegisterすることがありません。

WiFi経由でも3G/4G経由でもglobal上のAsterisk@VPSに対してRegisterするようにすることで上記を解決しています。

これまでセキュリティの確保をVPNが兼ねていたのですがシグナリングをTLS、メディアをSRTPで確保します。Asterisk@VPS上でDTLSの設定をすませていたのでDTLSでいきたかったのですがSessionTalkが非対応のようでした。

また Asterisk@Raspberry Pi ↔︎ Asterisk@VPS 間の接続ですが、HGW側とVPS側のセキュリティ確保、メディアのNAPT、etc…を考えたところIAX2での接続としました。IAX2はシグナリングとメディアを単一のUDPポートで伝送するためやはり色々と楽できました。

運用してみて

内線着信のpush対応ですが現在(2019-02-18)まで数ヶ月間ほど運用していますがピンチになる問題はありませんでした。運用初期ではSessionTalk LtdのSIP ProxyのIPが非公開のようでAsterisk@VPSにRegisterしてくるIPの確認とホワイトリスト設定の発生が多々ありましたがほぼ収束して(洗い出せて)いるようです。場所的にVPSが海外にあるのRTPの遅延が結構出るかなと考えていたのですが実通話では違和感なく会話が成立しています。ここらへん Asterisk@Raspberry Pi↔︎Asterisk@VPS の CODECと Asterisk@VPS↔︎SessionTalk@smartphoneのCODECにも依存しているようで、カットアンドトライが必要でした。

副産物としてSIPクライアントの比較、CODECの比較、コスパ比較などを行なったので別記事でいずれアップしていきたいと考えています。