Android では GS Wave または zoiper が高評価ですし、ほかにもいくつかあり、色々試して自分環境にあったソフトフォンを使えます。
ですが、iPhone 用は少し厄介です。
というのは、GS Wave や zoiper などの非プッシュ系のアプリの場合、バックグラウンド動作させていないと着信しませんが、これが恐ろしくバッテリー消費するのです。
2.5 %/1h くらいの消費量です。
プッシュ系だとこの3分の1程度で済みます。
ところがプッシュ系はバッテリー消費は抑えられるものの、別の問題があります。
プッシュ系で代表的なものは Acrobits ファミリーです(Acrobits / Groundwire / CloudSoftphone)。
Acrobits は一般用、Groundwire は企業向け、CloudSoftphone は ITSP 向けと、それぞれがなっているようで、050Free 改め My050 はこの CloudSoftphone です。
SMARTalk もまた、CloudSoftphone です(G-Call050 も同じです)。
単独デバイスに単独アカウントを設定して使う場合は気にするような問題はありません。
ブラステルと G-Call050 は一つのアカウントを複数デバイスに設定して、そのいずれも着信する、ということが可能になっています(非推奨な使い方ですから、自己責任です)。
例えば ATA(アナログ・テレフォニー・アダプター)を介してブラステル電番をイエデン化したとします。
スマホのソフトフォンにもこの電番を設定しておくと、イエデンにかかってきた電話を外出先でスマホで受話できるのです。
これは大変に便利です。
ところが、スマホ側がプッシュ系のソフトフォンの場合、イエデンやスマホが音声不通になるという厄介な問題に遭遇します。
この状態になったら、プッシュ系ソフトフォン側を非プッシュに設定して SIP 登録し直し、イエデン側も念のために再起動(再レジスト)してやっと音声不通状態が解消します。
どうしても駄目な場合は、ブラステルの当該アカウントにログインしてパスワード変更し、 SIP 登録状態を初期化する必要があるかも知れません。
これは非常に厄介です。
Android 機ではバックグラウンド常駐ソフトフォンでも、さほど問題にならないバッテリー消費が、iPhone では恐ろしいほどに消費されてしまうのですが、かといってプッシュ系のソフトフォンとイエデンが共存できないという厄介なことになるわけです。
さぁ、困りました。
Asterisk 側でイエデン着信を別電番に転送し、転送された電番をプッシュ着信で受ける、ということをするしかないかと思っていました。
SessionTalk Pro Softphone という UK 製のソフトフォンアプリがあります。
Callkit にも対応しているようです。
有料版(Pro 版)はプッシュとマルチアカウントに対応していて、Apple Store では 600円、Google Play では 430円ですから Acrobits よりは少し安価です。
まだ評価途上なのでハッキリしたことはいえないのですが、プッシュ系でありながら Acrobits の場合のような音声不通問題がないようなのです。
音声不通問題がないならば Asterisk を使わないで、iPhone でイエデンを持ち歩きながらバッテリー消費を抑えることが可能になります。
【追記】結論的に、この SessionTalk Pro Softphone を使うことにしました。
SessionTalk Pro Softphone のプッシュは次のように機能するようです。
「SIP アカウント情報は、安全な https 接続を介して SessionTalk 社のプッシュサーバーに転送され、そのプッシュサーバーがプロバイダへの SIP 登録(レジスト)を代行する。
着信があった場合、アプリを完全に閉じていてもプッシュサーバーを通じて iOS デバイスに通知され、アプリが呼び起こされて着信します。」
つまり、
プッシュの場合:
プッシュサーバーが IP 電話プロバイダへの SIP 登録を代行し、発着信もプッシュ
サーバーを経由して行うようです。
非プッシュの場合:
発着信は IP 電話プロバイダとソフトフォンの間で行われる。
ということです。
また、iOS 版の「プッシュ」には「同期登録(SIP のプッシュサーバーへの登録の仕方?)」というオプションが設定できますが(デフォルトでは設定されている)、どういう意味があるのかは不明です。
Android 版にはこのオプションはありません。
プッシュメカニズム自体は SessionTalk も Acrobits や CloudSoftphone と同様の仕組みですが、「プッシュ」と「非プッシュ」の混在登録時でもうまくどちらも着信・通話が可能で音声不通問題はないようです。
これは Android(プッシュ)と Android(非プッシュ)の組み合わせでも、iOS(プッシュ)と Android(非プッシュ)の組み合わせでも iOS(非プッシュ)と Android(プッシュ)のいずれの組み合わせでも問題はでていません。
残念ながら iPhone は1台しか持ち合わせていませんので iOS 同士での「プッシュ」と「非プッシュ」の組み合わせは検証できていまっせんが、おそらく問題ないと思われます。
【2019/06/02 プッシュ動作の検証の追記】
同じプッシュでも Acrobits 系と SessionTalk では非プッシュ側(GS Wave)との同時着信時動作が異なることがわかりました。
Acrobits 系との組み合わせでは呼び出し側(同じブラステルの別電番)のユーザーID での呼び出しに応じるか、電番での呼び出しに応じるかの選択ができるメニューが、非プッシュ側に出ます。
このいずれで応じるかによって、次回 Acrobits 側での受話が無音になるかならないかが左右されるような動作をします。
SessionTalk と GS Wave の組み合わせではこのような選択メニューは現れません。
どうもプッシュサーバーがプロバイダに代行登録(REGISTER)する際の SIP ID が「ユーザー ID」 か「電番」かで扱いが異なり、それがプロバイダ側での扱いの差異になっているようなのです。
ユーザー ID の場合: 12345678@softphone.spc.brastel.ne.jp
電番の場合 : 05068680987@softphone.spc.brastel.ne.jp
通常、ソフトフォンからプロバイダへの REGISTER はブラステルの場合、「ユーザー ID」で行われるようです(ソフトフォンによると思われます)。
このときに、プッシュサーバーが「ユーザー ID」で登録代行している場合は「無音問題」
がないように見受けられます。
ところが、プッシュサーバーが 「電番」で登録代行している場合(Acrobits 系はこちらと思われる)は「無音問題」に遭遇するのではないかと思われます。
ブラステルは非推奨ながら「同一アカウントの複数デバイスからの登録(REGISTER)」ができる、とホームページにもあります。
このときのブラステルの SIP サーバーの動作と関連していると思います。
ブラステルでは【「デバイス1」の「電番1」】から【「デバイス2」の「電番1」】を呼び出しが可能で(ある電番から同一電番の呼び出し)、このときに通話可能なケースと通話不可のケースがありますが、どうやらこの事象に類似しているように思います。
このような場合の、「通話可能/不可」は使うソフトフォンやデバイス特性(?)に関連していそうですが、よくはわかりません。
まだまだ大雑把な状況把握ですので、引き続き調べてみたいと思います。
SIP ログを分析すればもう少し、このあたりの動作状況がわかるのではないかと考えます。
-------------------
米中の通商問題、機密保護問題からファーウェイおよびその新端末(P30)が大きな影響を受けています。
これ以前の機種の場合(P20以前)、ファーウェイはセキュリティアップデートは提供する、といっており、 Google も既存機種へのサポートは継続するようですが、いつこれがひっくり返るようなことにならないとも限りません。
そうなると、国産機か非中華製の Android 機、または iPhone にしなくてはならなくなってしまいます。
iPhone は SE 以降では 6s/7/8 くらいがおすすめ機種と「私は」勝手に思っていますが、ソフトフォンも光明が射してきました。
4 件のコメント:
以前にGrandstreamのことでお世話になったものです。その節はありがございました。この記事とは少し話題がずれますが、一つお聞きしたいことがあり、再度失礼します。
私のところでも遅ればせながらイエ電計画をし、HT801とバックアップ用にPAP2-NAを購入しました。両方共設定が済み、順調に稼働することが確認できました。両者の大きな違いはナンバーディスプレイが使えるかどうかですが、PAP2-NAはdefaultで Bellcore, bell202が設定されています。ここにNTT方式を設定できないのがナンバーディスプレイが使えない原因ですが、ナンバーディスプレイのためのデータであるCaller IDというのはその国で発信されたものに依存すると思います。もしアメリカからの呼び出しがあった場合はPAP2-NAでもナンバーディスプレイが機能するということでしょうか?
ナンバーディスプレイの動作を完全に理解しているわけではないのでお聞きしている次第です。よろしくお願いします。
こんにちは。
お返事が遅れてスミマセン。
PAP2-NA は日本のナンバー・ディスプレイには対応していないようです。
Grandstream のHTシリーズは「Caller ID Scheme:NTT Japan」を選択できますので、大丈夫ですがPAP2-NA は日本仕様は選択できないようですね。
米国からの呼び出しで米国の交換機が日本の交換機に渡したときにNTT側で日本仕様のナンバーディスプレイに変換していますので国内仕様のATAならば表示されるはずですが、米国仕様のATAの場合は表示されないと思われます。
したがって、最終的にナンバーが表示されるかどうかはやってみないとなんとも言えません。
やはり日本の交換機に届いた時点でNTT方式に変換されるのですね、するとPAP2-NAでの表示は無理と推定できますね。これに関連してもう一つ失礼します。IP電話についてはCaller IDを何にするかは別にNTT方式に縛られる必要は無いような気がするのですが、これについてもどこかでNTT方式になると理解しました。ナンバーディスプレイで確認するとHT801では表示しますが、PAP2-NAでは駄目です。なお、PAP2-NAのログを確認すると、ログの中には受信した局の電話番号が見えます。したがって問題はナンバーディスプレイの表示側(つまり電話機側)の対応に依ると推定しました。
どうもありがとうございました。
Caller ID を交換機から電話機(またはATA)に渡すインターフェースと電話機側が一致していないとうまく表示されないと思います。
今回のケースでは電話機は国内仕様と思われますからOKですが、ATAが国内仕様でないためにNGなのだと思われます。
米国仕様での発信 -> 米国交換機 -> NTT交換機(国内仕様に変換)-> ATA(米国仕様)NG ->
電話機(国内仕様だがATAですでにNG)-> ナンバー表示されず
ということでしょう。
コメントを投稿