050plus / SMARTalk / 050Free / LaLa call 等のいずれも Google Play store での評価点は軒並み ３.０ 〜 ３.３ です。
少なくとも ４.０ 以上は欲しいと思います。
IP 電話自体はネット環境やサーバー性能、端末性能などが４G になってからは劇的に改善されてきていて固定電話と遜色ないところまできています（固定電話も「黒電話」を除けば IP 電話なのですが）。
２０１６年以前はまだまだ使えるレベルには達していなかったのが、２０１６年秋頃からすごくよくなった、という印象です。
ところが各サービスの「公式アプリ」は安心して使えるレベルにはまだ達していない、というのが実情だと思います。
そのため「IP 電話は使えない」という認識がまだまだ多くあり大変残念です。
すでに NTT の「ひかり電話」も IP 電話です。
インターネット経由の IP 電話か、NTT 直収の IP 網での IP 電話かの違いはあっても同じ IP 電話なのです。
米国には NTT のような存在はありませんからすべてがいまやインターネットによる IP 電話です。
こういう状況を踏まえると日本の電話事業は相変わらず NTT（および総務省）が仕切っている感じで、これが IP 電話事業を限定的にしてしまっているのが実情です。
欧米の IP 電話サービスのように「推奨アプリ」と「プロビジョニング」の対応にした方がいいと思いますが、なぜか「固有のアプリ」にこだわって、しかも作りが決してよくないという悲惨な状況です。
各サービス事業者は一度気持ちをクリアにしてご自分たちのサービスのあり方を見直して欲しいものです。
みなさんは「公式アプリ」の低評価どおりの問題にぶち当たり、ほかの VoIP アプリをあれこれ試行されてお使いになっておられると思うのです。
「ほかのアプリ」で仮に問題が生じても「公式アプリ」ではないので「サポート外の使い方なので相談に乗れません」と冷たくあしらわれていると思います。
そういう方々がお困りになってネット情報を検索しああでもない、こうでもない、と日夜（？）奮闘されていて、そういう方々の一部の方々が当ブログも閲覧くださっていると思うのです。
ワタシはサービス事業者の提供してる「公式アプリ」も評価試用し、ほかの VoIP アプリもいろいろ試用・本運用してきました。
その中でこれはよい、と思うものもいくつかあり、日々進化しているように思いますが、ときにアップデートがグレードダウンしたりして、一層混乱状態を引き起こしているように思います。
端末の OS バージョンとの関係もあったりします。
つまり扱うためのパラメーターが多すぎるのです。
そこでできるだけ単純化して使う、あれこれ試すのは単純な使い方がうまくいってからにする、というのがコツだと思っています。
例えば、コーデック一つをとってみても G.711μ-law（PCMU と表現している場合もありますが同じものです）一本だけにします。
これでうまくいかないから、といってほかのコーデックに手を出してもパラメーターが増えて混乱するだけです。
G.711μ-law でうまくないなら、それはコーデックの問題ではなく別の問題があるからです。
最近思うのは「プッシュ着信」の問題です。
どうも試行した限りでは「プッシュ着信」は問題を大きくするだけでなんらメリットはない、とまで思うに至りました。
常駐型ではバッテリー消費が半端ないから、とお嘆きあなた、実はバッテリー消費が半端ないのはその VoIP アプリのせいばかりではないのです。
ワタシがこれまで経験した範囲では 1 % / 1h 程度なら容認の範囲ということです。
これ以下になることも少なくありませんし、多少コンマ何％か増えたところで問題にするほどではありません。
アプリをインストールして設定して、そのあとキャッシュをクリアし、強制再起動してみればほとんどのケースでバッテリー消費は 1 %以下 / 1h に収まっています。
「プッシュ着信」アプリの設定を「プッシュ着信」のままほかの常駐型アプリを設定した場合、片通話や無音問題を引き起こします。
こういうことはサービス事業者も「公式」には情報開示していません。
（「公式アプリ」が「プッシュ」対応しているのでいい難いのかも知れません）
ですから、「プッシュ着信」アプリは「非プッシュ」に設定し終了させる、実行中アプリリストからも終了させる、ということをしたあとに常駐型アプリの設定をするように注意が必要です。
ほとんどのサービス事業者の「公式アプリ」は「プッシュ着信」対応型になっており、これが引き起こす問題に最近一層の注意が必要だと強く感じるようになりました。
着信の確実性は「プッシュ」である必要はありません。
それよりも「プッシュ」が引き起こす問題を回避するためには「プッシュ型アプリ」の「プッシュ」は強くオススメしません。
Acrobits 系はこの「プッシュ」に対応しているアプリの一つで、異論はもちろん承知の上でいいますが「プッシュ設定での使用」はワタシはあまりオススメしません。
とにかく「常駐型」アプリをできるだけ単純化して問題の根っこを早く見つけることが結果的によい状態になる、ということです。
2018-10-06
2018-10-04
ブラステルとプッシュ系ソフトフォンアプリの留意事項
ブラステルは複数デバイスに同一アカウントを登録できますのでこのような使い方がしたいときがあると思います。
ブラステルは複数デバイスへの登録は強く非推奨な使用法としていますのでサポート対象外になりますから、自己責任ということになります。
それでも例えば、イエデンにブラステルを登録して外出中でも着信を受けたい、というような場合があります。
転送設定して別の電話（携帯電話や他社 050 アカウントの電話）で受ける、というのが普通の使い方なのですが、 一定時間呼び出し後に転送または即時転送の場合、外出のたびに転送設定し直すなど多少の面倒臭さがあります。
またブラステルの転送は転送先に発信元電番は表示されず着信電番（転送設定した電番）が表示されますので、転送先で受ける際誰からの電話なのかがわかりません（SMARTalk は転送しても発信元電番が通知されます）。
そこで複数デバイスに同一アカウントを登録して使いたいわけです。
これは外出中に限らず、スマホをウチの中でも子機扱いできる使い方でもあるのです。
イエデン用のアナログアダプターは通常はプッシ着信には対応していません（常時起動待受状態ですからそもそもプッシュは必要としません）。
同一アカウントを 050Free にも登録してこれをプッシュ着信に設定すると、イエデンも 050Free も無音になったり、片通話になったりします
ブラステルは非推奨ですが、こういう使い方をしたい場合は非プッシュ着信のアプリを使う必要があります。
プッシュ着信対応しているソフトフォンは Acrobits 系（Acrobits、Croud Softphone、Groundwire、050Freeなど）や他 ITSP（SMARTalk [Acrobits 系か？]、050plus など） があります。
ブラステルの場合、Acrobits 系を使ってプッシュ着信設定し、イエデンにも登録すると無音・片通話問題を引き起こします
そこで、複数デバイスに同一アカウントを登録の場合は、非プッシュのソフトフォンアプリを使用します。
また、それらのコーデックはすべて同じコーデックを使う設定にする必要があります。
具体的には G.711μ-law（PCMU と表現している場合もあります）のみに設定します。
非プッシュのソフトフォンは GS Wave、Zoiper、CSiｐSimple、MizuDroid などがあります。
プッシュ系にも設定してしまったときは、プッシュ系のソフトフォンアプリの「プッシュ着信」を「発信のみに使用」または「オフ」にし、そのアプリを終了させます。
この段階でアンインストールしても構いません。
非プッシュ系のソフトフォンアプリもすべて非 Active にします。
その後ブラステルのマイページに入り、「パスワード」を再発行します。
「パスワード」の再発行で、サーバーのレジスト状態がクリアされるようです。
その後にイエデンのアダプターのパスワード再設定を行い Reboot します。
これが Register 状態になったら、ほかのデバイスの非プッシュのソフトフォンアプリを起動し、これもパスワード再設定し Active にします。
以上の手順で複数デバイスへの設定が終わります。
あとは普通に発着信できるようになります。
イエデンへの着信もスマホで受けることも可能です。
このような使い方で、実際にイエデンにかかってきた電話を、外出中に何度か受けたことがありますが、相手はイエデンと話していると思ってくれていたようです。
複数デバイスに同一アカウントをプッシュ着信のアプリに設定してはいけません
実は 050FRee はプッシュ着信設定していても常時起動状態です。
おそらく Doze が関係していると思われますが、常時起動ならばプッシュである必要もないのですが、なぜかこういう動作をしています。
ですから、このことでバッテリー消費が抑えられるわけではありません。
なお、ブラステルの SIP サーバーは kamailio (4.1.0-pre0 (x86_64/linux)) です。
Kamailio は Asterisk のようなオープンソースの SIP サーバーです。
そのため複数デバイスへの同一アカウントの登録が可能になっていると思われます。
SIP サーバーでは内線扱いでゲートウェイしているようです。
ブラステル以外からの着信の場合、相手アカウントは 172.16.0.0/16 〜 172.31.0.0/16 のプライベートアドレスと内線アカウントを割り当てられて発着信や音声ストリームのやり取りをしているようにログからは見えます。
ブラステルからブラステル以外への発信の場合は、ブラステル側は 172.16.0.0/16 〜 172.31.0.0/16 を割り当てられ、相手側は 192.168.0.0/16 が割り当てられるようですから、どちらも内線扱いでゲートウェイしているように見えます。
ブラステルからブラステルの場合は発信側は 172.16.0.0/16 〜 172.31.0.0/16 のプライベートアドレス、着信側はブラステルの SIP プロキシアドレスが割り当てられているように見えます。
実際のところはよくはわかりませんが、ログを見る限りこのような振る舞いをしているように思えます。
ブラステルは複数デバイスへの登録は強く非推奨な使用法としていますのでサポート対象外になりますから、自己責任ということになります。
それでも例えば、イエデンにブラステルを登録して外出中でも着信を受けたい、というような場合があります。
転送設定して別の電話（携帯電話や他社 050 アカウントの電話）で受ける、というのが普通の使い方なのですが、 一定時間呼び出し後に転送または即時転送の場合、外出のたびに転送設定し直すなど多少の面倒臭さがあります。
またブラステルの転送は転送先に発信元電番は表示されず着信電番（転送設定した電番）が表示されますので、転送先で受ける際誰からの電話なのかがわかりません（SMARTalk は転送しても発信元電番が通知されます）。
そこで複数デバイスに同一アカウントを登録して使いたいわけです。
これは外出中に限らず、スマホをウチの中でも子機扱いできる使い方でもあるのです。
イエデン用のアナログアダプターは通常はプッシ着信には対応していません（常時起動待受状態ですからそもそもプッシュは必要としません）。
同一アカウントを 050Free にも登録してこれをプッシュ着信に設定すると、イエデンも 050Free も無音になったり、片通話になったりします
ブラステルは非推奨ですが、こういう使い方をしたい場合は非プッシュ着信のアプリを使う必要があります。
プッシュ着信対応しているソフトフォンは Acrobits 系（Acrobits、Croud Softphone、Groundwire、050Freeなど）や他 ITSP（SMARTalk [Acrobits 系か？]、050plus など） があります。
ブラステルの場合、Acrobits 系を使ってプッシュ着信設定し、イエデンにも登録すると無音・片通話問題を引き起こします
そこで、複数デバイスに同一アカウントを登録の場合は、非プッシュのソフトフォンアプリを使用します。
また、それらのコーデックはすべて同じコーデックを使う設定にする必要があります。
具体的には G.711μ-law（PCMU と表現している場合もあります）のみに設定します。
非プッシュのソフトフォンは GS Wave、Zoiper、CSiｐSimple、MizuDroid などがあります。
プッシュ系にも設定してしまったときは、プッシュ系のソフトフォンアプリの「プッシュ着信」を「発信のみに使用」または「オフ」にし、そのアプリを終了させます。
この段階でアンインストールしても構いません。
非プッシュ系のソフトフォンアプリもすべて非 Active にします。
その後ブラステルのマイページに入り、「パスワード」を再発行します。
「パスワード」の再発行で、サーバーのレジスト状態がクリアされるようです。
その後にイエデンのアダプターのパスワード再設定を行い Reboot します。
これが Register 状態になったら、ほかのデバイスの非プッシュのソフトフォンアプリを起動し、これもパスワード再設定し Active にします。
以上の手順で複数デバイスへの設定が終わります。
あとは普通に発着信できるようになります。
イエデンへの着信もスマホで受けることも可能です。
このような使い方で、実際にイエデンにかかってきた電話を、外出中に何度か受けたことがありますが、相手はイエデンと話していると思ってくれていたようです。
複数デバイスに同一アカウントをプッシュ着信のアプリに設定してはいけません
実は 050FRee はプッシュ着信設定していても常時起動状態です。
おそらく Doze が関係していると思われますが、常時起動ならばプッシュである必要もないのですが、なぜかこういう動作をしています。
ですから、このことでバッテリー消費が抑えられるわけではありません。
なお、ブラステルの SIP サーバーは kamailio (4.1.0-pre0 (x86_64/linux)) です。
Kamailio は Asterisk のようなオープンソースの SIP サーバーです。
そのため複数デバイスへの同一アカウントの登録が可能になっていると思われます。
SIP サーバーでは内線扱いでゲートウェイしているようです。
ブラステル以外からの着信の場合、相手アカウントは 172.16.0.0/16 〜 172.31.0.0/16 のプライベートアドレスと内線アカウントを割り当てられて発着信や音声ストリームのやり取りをしているようにログからは見えます。
ブラステルからブラステル以外への発信の場合は、ブラステル側は 172.16.0.0/16 〜 172.31.0.0/16 を割り当てられ、相手側は 192.168.0.0/16 が割り当てられるようですから、どちらも内線扱いでゲートウェイしているように見えます。
ブラステルからブラステルの場合は発信側は 172.16.0.0/16 〜 172.31.0.0/16 のプライベートアドレス、着信側はブラステルの SIP プロキシアドレスが割り当てられているように見えます。
実際のところはよくはわかりませんが、ログを見る限りこのような振る舞いをしているように思えます。
2018-10-02
050Free と Cloud Softphone
ブラステルの公式アプリである 050Free は Acrobits 社の無料版である Cloud Softphone をベースにカスタマイズされているはずなのですが、両者にアイコン以外の違いはないようです。
というか、Cloud Softphone を最初の起動時に Cloud ID に "brastel" と入力すると 050Free にカスタマイズされる、ということみたいです。
実は着信呼び出し中に任意の番号に転送することができます。→ 最新版はバグでNG
この転送の場合、転送先にブラステル番号も指定できます（ブラステルのマイページからの転送はブラステル番号への転送設定はできません）。
また、転送先には発信元番号が表示されます（ブラステルのマイページからの転送は転送元番号が表示され、発信元番号は表示されません）。
この「転送」は SIP REFER メソッドに対応したもので、ブラステルのホームページにはこれに関する情報はないのですが、実際にできるところをみるとブラステルの SIP プロキシは REFER メソッドに対応していると思われます。
なお、アプリには自動転送機能も実装されているのですが実際には機能しません。
英米の ITSP はアプリの設定による自動転送ができますので多くの VoIP アプリがこの機能を実装しているのですが国内の ITSP ではアプリでの自動転送には対応していないようです。
050Free は実はマルチアカウントに対応していて、ブラステルだけではなく例えば FUSION IP-Phone Smart やほかの 050 サービスのアカウントも登録でき、主アカウント以外も着信します。
VoIP アプリとしてはかなり優秀かも知れません。
コーデックが GSM / G.711μ-law の２つだけですが問題はありません。
一般電話や携帯電話との通話を考慮すると G.711μ-lawを優先するのがいいと思います（G.711μ-law のみでもかまいません）。
ディープスリープ中でも着信します。
GCM によるプッシュ着信に対応しています。
SMARTalk も 050Free と設定時の項目や画面が似通っていますので同じ Acrobits 系と思われますが、こちらはコーデックに iLBC と G.722 も使えるようになっているほか、マルチアカウントもできますが FUSION IP-Phone Smart の別のアカウント追加に限定されています。
050Free 最新版は 2.0 ビルド 1101593 ですが、まだ少しバグがあるようで普段使いには差し障りはないのですが、REFER メソッドによる転送、高度な機能の設定変更などが無視されたり、ポストフィックスがうまく機能しないなどがあるようです。
ポストフィックスというのは、ほかのソフトフォンアプリにはあまりない、珍しい機能です。
プリフィックスはどのソフトフォンアプリでもありますが、ポストフィックスというのは電番の後ろに追加する機能です。
例えば 0120 などで IVR により「１〜３」を選択してください、つぎに「１〜６を選択してください」などとあったときに ",,,,,3#,,,,,2#" としておくと最初は「３」つぎに「２」を自動的に応答してくれます。
ブラステルの「◯◯分ご利用いただけます〜〜〜〜」の冒頭のアナウンスを回避するために "05068" で始まる番号（ブラステル）以外には ",****##" を付加する設定でこのアナウンスを自動的にやめることが可能になるのです。
残念ながら、最新版はこの機能がバグでうまく動作しません。
次の修正版で改修されることを願っていますが。。。
本来的にはブラステルがこのイヤなアナウンスをやめてくれることを願っていて、ブラステルには何度もお願いしていますが。。。
ほかの人たちの中にもこのようなアナウンスをやめて欲しいという依頼をされているようでネットを散見すると結構いらっしゃるのに、ブラステルは頑なです。
これさえなければいいのですが。
2018-10-01
2018-09-04
PSTN 網と インターネット
PSTN：Public Switching telephony Network、公衆交換電話網（一般加入回線電話網）は「Common Channel Signaling System No.7、SS7」という世界共通の信号方式で接続されています。
発呼すると、自電話が登録されている交換器から STP（Signal Transfer Point）へ、着呼側電番が登録されている交換機を問い合わせます。
このときに SS7 を使って問い合わせます。
交換器には固有の「ポイントコード」が割り振られていて信号制御はこのポイントコードで行われます（IP アドレスに似ています）。
着呼側交換機のポイントコードが得られると、その交換機と自交換機の間で通話用のトランクが開かれて呼び出し・通話、ということになります。
この仕組みはインターネットの仕組みと非常に似通っています。
つまり、通信相手の IP アドレスを DNS（Domain Name Server）に問い合わせて、IP アドレスを得て、その IP アドレスで相手と通信しているわけですが、DNS は位置づけが PSTN における STP と同じです。
もちろんインターネットよりも電話交換網の方がずーっと古くからあり、Arpa ネットから発展したインターネットが交換網の仕組みを参考にしたのではないかと思っています。
インターネットには表のラインと裏のラインがあって、表が IP アドレスならば裏は DNS と言えるでしょう。
電話網の電番とポイントコードの関係と同じ仕組みです。
シグナリングプロトコルはそのバージョンが SS5、SS6、SS7 のようにアップしてきて最終バージョンが SS7です。
NTT の場合「D70改」という交換機が最後に開発された交換機で実に２５年間も使われました。
そこで、すべての交換網をインターネット交換網に置き換えてきたわけです。
現在 NTT はバックボーンはすでに IP 網になっています。
ラスト１マイルを完全 IP 化したいようですが、容易ではありません。
ひかり電話になっていればすでに IP 電話ですが、いわゆる黒電話がまだ残っており、これをどうするかなのですが、モデムを無償貸与することでこれを解消しようと考えているようです。
黒電話は交換局から電源を得ており、自宅が停電でも電話は使えますが、モデムになるとこれが使えなくなります。
こういうこともキチンと説明しなければなりませんが、逆にモデム設置を躊躇する方もでてきてそれが大変なわけですが、どこかで半強制的に移行せざるを得ないと思われます。
さて、完全 IP 化ができたとして、インフラはインターネットプロトコルになりますが、サービスはどうでしょうか。
実はここが問題です。
例えば、米国ではいろいろなサービスが試行または実用化されており、SMS は固定電話でも使えますが、日本ではできるのに携帯電話網にしか開放していません。
こういうことがまだまだサービス面の課題なわけですが、一向にサービス面の議論がされているようには感じません。
インフラの IP 化だけが議論されているように感じています。
IP 電話も、一部の 050 扱いのままですが、地域性のない、個人に割り当てた電番、という本来の「ワンナンバー」 にならないものでしょうか。
発呼すると、自電話が登録されている交換器から STP（Signal Transfer Point）へ、着呼側電番が登録されている交換機を問い合わせます。
このときに SS7 を使って問い合わせます。
交換器には固有の「ポイントコード」が割り振られていて信号制御はこのポイントコードで行われます（IP アドレスに似ています）。
着呼側交換機のポイントコードが得られると、その交換機と自交換機の間で通話用のトランクが開かれて呼び出し・通話、ということになります。
この仕組みはインターネットの仕組みと非常に似通っています。
つまり、通信相手の IP アドレスを DNS（Domain Name Server）に問い合わせて、IP アドレスを得て、その IP アドレスで相手と通信しているわけですが、DNS は位置づけが PSTN における STP と同じです。
もちろんインターネットよりも電話交換網の方がずーっと古くからあり、Arpa ネットから発展したインターネットが交換網の仕組みを参考にしたのではないかと思っています。
インターネットには表のラインと裏のラインがあって、表が IP アドレスならば裏は DNS と言えるでしょう。
電話網の電番とポイントコードの関係と同じ仕組みです。
シグナリングプロトコルはそのバージョンが SS5、SS6、SS7 のようにアップしてきて最終バージョンが SS7です。
NTT の場合「D70改」という交換機が最後に開発された交換機で実に２５年間も使われました。
そこで、すべての交換網をインターネット交換網に置き換えてきたわけです。
現在 NTT はバックボーンはすでに IP 網になっています。
ラスト１マイルを完全 IP 化したいようですが、容易ではありません。
ひかり電話になっていればすでに IP 電話ですが、いわゆる黒電話がまだ残っており、これをどうするかなのですが、モデムを無償貸与することでこれを解消しようと考えているようです。
黒電話は交換局から電源を得ており、自宅が停電でも電話は使えますが、モデムになるとこれが使えなくなります。
こういうこともキチンと説明しなければなりませんが、逆にモデム設置を躊躇する方もでてきてそれが大変なわけですが、どこかで半強制的に移行せざるを得ないと思われます。
さて、完全 IP 化ができたとして、インフラはインターネットプロトコルになりますが、サービスはどうでしょうか。
実はここが問題です。
例えば、米国ではいろいろなサービスが試行または実用化されており、SMS は固定電話でも使えますが、日本ではできるのに携帯電話網にしか開放していません。
こういうことがまだまだサービス面の課題なわけですが、一向にサービス面の議論がされているようには感じません。
インフラの IP 化だけが議論されているように感じています。
IP 電話も、一部の 050 扱いのままですが、地域性のない、個人に割り当てた電番、という本来の「ワンナンバー」 にならないものでしょうか。
登録:
投稿 (Atom)