Root - PNF は端末をルート化していなくても GCM の状況を見ることができます。
アプリは下記にあります。
https://play.google.com/store/apps/details?id=com.andqlimax.pushfixer
起動すると最初に次のような画面になります。
Play sevices monitor をクリックすると次の画面になります。
これは Google play開発者サービスのログになっていて、状況を見ることができます。
ハートビート間隔が 550s になっているのが見て取れます。
ほかにもハートビートが成功した回数・失敗した回数、ネットワークタイプ等がわかります。
右上の EVENTS をクリックすると次の画面になります。
画面をスクロールして一番下が最新、上が古いログになっており、ログは一定量になると古いものが消されて新しいものが追加されます。
時刻・net=0(モバイルを表します)/ net=1(WiFi を表します)・Sent Client HB(クライアントからハートビートを送信したことを示します/サーバーから送られてきた場合はそのようにログされこの場合はクライアント側から ACK が返されます)がわかりその間隔が次行の時刻との差でわかります。
10:09 08:26:44.098 Exiting doze → Doze から抜けたことを示します
10:09 08:26:44.099 Sent com.google.android.gsf.gtalkservice → GCM が動作しています
10:09 08:26:51.258 Received jp.co.fusioncom.smartalk.android result=1 time=187 p=10 → この時刻に SMARTalk からの通知を受け取ったことを示しています(着信通知です)
そのあと発信側で呼び出しをとりやめましたので Close err:FIN time=5745 と記録されています。
また、WiFi に接続変更しましたので net=1 に切り替えられたログが記録されています。
つまりログ上は GCM が動作しており、Doze 状態から脱却して SMARTalk がほかからの呼び出しで着信動作に入ったということがわかります。
発着信の動作が不安定などの場合にこのようなシーケンスで動作しているかどうかで不具合の発見に役立てることができます。
常駐型ソフトフォンアプリの場合は少し違うシーケンスになります。
Doze に入っていなければログ上の変化はありません。
ページ
▼
2018-10-07
Bluetooth スピーカー
Sound Blaster 社製の一部機種と SONY のこのシリーズくらいです。
ミニコンポが2セットのほか5ch 対応セットもありますので、AUX 出力対応品を探していました。
Bluetooth アダプターという手もありましたが、本品のようなスピーカーは手軽なのでどうせなら、と AUX 出力可能なものにしました。
ということで、SONY の SRS-BTS50 Black を購入しました。
すでに製造中止機種なので、品薄になっていると思います。
少し高音域の伸びが気になりますが、まぁまぁこの価格帯では妥協も仕方がないでしょう。
カミさんが自分のスマホで楽曲を聴いているのを見ていて、スピーカーを用意してみたらどうだろうか、ということで購入しました。
最初は「自分(カミさん)のためではなくワタシ自身が使うために購入したのでは?」とカミさんにいわれましたが「いやいや、これはアンタのために買ったんだよ」といって使わせたところ、大変気に入ってくれましたから買ってよかったと思います。
1台目のペアリング方法と2台目以降のペアリングの仕方が異なっていて、2台目のペアリングに少し戸惑いましたが、無事にこれもペアリングできました。
マニュアルは丁寧に読むものだと改めて感じた次第でオハズカシイ。
2018-10-06
IP電話サービスの公式アプリってどれも問題があるように思えます
050plus / SMARTalk / 050Free / LaLa call 等のいずれも Google Play store での評価点は軒並み 3.0 〜 3.3 です。
少なくとも 4.0 以上は欲しいと思います。
IP 電話自体はネット環境やサーバー性能、端末性能などが4G になってからは劇的に改善されてきていて固定電話と遜色ないところまできています(固定電話も「黒電話」を除けば IP 電話なのですが)。
2016年以前はまだまだ使えるレベルには達していなかったのが、2016年秋頃からすごくよくなった、という印象です。
ところが各サービスの「公式アプリ」は安心して使えるレベルにはまだ達していない、というのが実情だと思います。
そのため「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 系はこの「プッシュ」に対応しているアプリの一つで、異論はもちろん承知の上でいいますが「プッシュ設定での使用」はワタシはあまりオススメしません。
とにかく「常駐型」アプリをできるだけ単純化して問題の根っこを早く見つけることが結果的によい状態になる、ということです。
少なくとも 4.0 以上は欲しいと思います。
IP 電話自体はネット環境やサーバー性能、端末性能などが4G になってからは劇的に改善されてきていて固定電話と遜色ないところまできています(固定電話も「黒電話」を除けば IP 電話なのですが)。
2016年以前はまだまだ使えるレベルには達していなかったのが、2016年秋頃からすごくよくなった、という印象です。
ところが各サービスの「公式アプリ」は安心して使えるレベルにはまだ達していない、というのが実情だと思います。
そのため「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-04
ブラステルとプッシュ系ソフトフォンアプリの留意事項
ブラステルは複数デバイスに同一アカウントを登録できますのでこのような使い方がしたいときがあると思います。
ブラステルは複数デバイスへの登録は強く非推奨な使用法としていますのでサポート対象外になりますから、自己責任ということになります。
それでも例えば、イエデンにブラステルを登録して外出中でも着信を受けたい、というような場合があります。
転送設定して別の電話(携帯電話や他社 050 アカウントの電話)で受ける、というのが普通の使い方なのですが、 一定時間呼び出し後に転送または即時転送の場合、外出のたびに転送設定し直すなど多少の面倒臭さがあります。
またブラステルの転送は転送先に発信元電番は表示されず着信電番(転送設定した電番)が表示されますので、転送先で受ける際誰からの電話なのかがわかりません(SMARTalk は転送しても発信元電番が通知されます)。
そこで複数デバイスに同一アカウントを登録して使いたいわけです。
これは外出中に限らず、スマホをウチの中でも子機扱いできる使い方でもあるのです。
イエデン用のアナログアダプターは通常はプッシ着信には対応していません(常時起動待受状態ですからそもそもプッシュは必要としません)。
同一アカウントを 050Free にも登録してこれをプッシュ着信に設定すると、イエデンも 050Free も無音になったり、片通話になったりします
ブラステルは非推奨ですが、こういう使い方をしたい場合は非プッシュ着信のアプリを使う必要があります。
プッシュ着信対応しているソフトフォンは Acrobits 系(Acrobits、Croud Softphone、Groundwire、050Freeなど)や他 ITSP(SMARTalk [Acrobits 系か?]、050plus など) があります。
ブラステルの場合、Acrobits 系を使ってプッシュ着信設定し、イエデンにも登録すると無音・片通話問題を引き起こします
そこで、複数デバイスに同一アカウントを登録の場合は、非プッシュのソフトフォンアプリを使用します。
また、それらのコーデックはすべて同じコーデックを使う設定にする必要があります。
具体的には G.711μ-law(PCMU と表現している場合もあります)のみに設定します。
非プッシュのソフトフォンは GS Wave、Zoiper、CSipSimple、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、CSipSimple、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 の2つだけですが問題はありません。
一般電話や携帯電話との通話を考慮すると G.711μ-lawを優先するのがいいと思います(G.711μ-law のみでもかまいません)。
ディープスリープ中でも着信します。
GCM によるプッシュ着信に対応しています。
SMARTalk も 050Free と設定時の項目や画面が似通っていますので同じ Acrobits 系と思われますが、こちらはコーデックに iLBC と G.722 も使えるようになっているほか、マルチアカウントもできますが FUSION IP-Phone Smart の別のアカウント追加に限定されています。
050Free 最新版は 2.0 ビルド 1101593 ですが、まだ少しバグがあるようで普段使いには差し障りはないのですが、REFER メソッドによる転送、高度な機能の設定変更などが無視されたり、ポストフィックスがうまく機能しないなどがあるようです。
ポストフィックスというのは、ほかのソフトフォンアプリにはあまりない、珍しい機能です。
プリフィックスはどのソフトフォンアプリでもありますが、ポストフィックスというのは電番の後ろに追加する機能です。
例えば 0120 などで IVR により「1〜3」を選択してください、つぎに「1〜6を選択してください」などとあったときに ",,,,,3#,,,,,2#" としておくと最初は「3」つぎに「2」を自動的に応答してくれます。
ブラステルの「◯◯分ご利用いただけます〜〜〜〜」の冒頭のアナウンスを回避するために "05068" で始まる番号(ブラステル)以外には ",****##" を付加する設定でこのアナウンスを自動的にやめることが可能になるのです。
残念ながら、最新版はこの機能がバグでうまく動作しません。
次の修正版で改修されることを願っていますが。。。
本来的にはブラステルがこのイヤなアナウンスをやめてくれることを願っていて、ブラステルには何度もお願いしていますが。。。
ほかの人たちの中にもこのようなアナウンスをやめて欲しいという依頼をされているようでネットを散見すると結構いらっしゃるのに、ブラステルは頑なです。
これさえなければいいのですが。