ANT+準拠の無線心拍計が届いた

ANT+無線心拍計のパッケージ

何年も前から、運動時の記録が残せるような心拍計が欲しかった。Androidが登場してからはAndroid端末と連動する心拍計が欲しくなった。今ならBluetooth Low Energy (BLE)準拠のものを選ぶのが妥当な判断だろうが、残念ながら自分の使いたい端末で対応していない。悩んだ結果ANT+準拠のものを注文した。

CooSpo ANT+無線心拍計

それが中国から6/28に届いた。6/11にebay.comで注文したことになっているから、2週間強かかったことになる。まぁ、早い方ではないだろうか。

商品写真では”CooSpo”というブランド名らしきものが印字されている。が、自分のところに配達されたものは無印。ちなみに、文字のスタイリィングによって、”p”がなかなか認識できなかった。が、”Coo(l)” + “Spo(rt)”ということなんだろう。わかってしまえばなぜわからなかったかの方が不思議なくらい。

だが、”CooSpo”がわかったからといっても特に意味がない。どこの会社のブランドであるか、とか、この心拍計のモデル名/番号があるか、などは全くの謎だ。まぁ中華グッズにはよくある話。

製品の形状・使用形態は同様の商品と基本的に同じだと思うが、チェストストラップの内側に電極部が

説明書によると、チェストストラップの内側に電極部がある（黄色線で囲んだ部分）ということだが、これは知らなかった。てっきり、計測器の裏側部分だけがそういう役目を果たすものと思っていた。この製品だけの話か、他の同様の製品にも当てはまるのか、自分にはわからない。

心拍計ユニットをストラップに固定するスナップの間隔は4.5cm

ただ、心拍計ユニットをストラップに固定するスナップの間隔が4.5cm、というのは標準サイズのようで（写真は、今回購入したCooSpoのものではなく、eBayの一リスティングから）、以前買った中国Kyto社のHRM-2830のものとサイズ的には互換性がある。だが、パッと試した範囲では、CooSpoの計測ユニットをHRM-2830のベルトにつけて見ても、スマホから心拍計に接続できなかった。これがひょっとするとHRM-2830が使えなかったことと関係しているのかもしれない。

ちなみに、中国Kyto社のHRM-2830と今回のCooSpoの比較というと、計測ユニットはどちらも横幅はほぼ同じだが、CooSpoのものの方が縦に若干長く、かつ厚い。そうはいっても、着用しているときには全く気にならない程度。

Xperia X10 Mini, Galaxy Note 3とも無事接続（両端）。だが、Xperia Acro IS11S（真ん中）はダメな模様。

早速、ANT+をサポートしているはずのXperia X10 Mini E10i, Xperia Acro IS11S、Galaxy Note 3 N-9005でテスト。GN3はストックROMのまま（ただしルート化済み）だが、X10 MiniにはGinger BreadベースのカスタムROM MiniCM 7をインストールしてあるし、AcroにはIce Cream SandwitchベースのカスタムROMがインストールしてある。それぞれ、ANT Radio ServiceとANT+ Pluginsの2つのアプリが最初からプリインストールされているか（GN3）か、このために自分でインストールした（他の2機種）。後日他の連携Androidアプリについても調べてみた。

その上でANT+ Heart Rate Grapherで心拍数をモニタしてみた。簡単なペアリングの後（Bluetoothのようにパスキーの入力などはない）、X10 Mini, GN3では写真のように無事計測し始めたが、Acroではうまくいかない。

「ハートレートセンサー購入しました」、「Xperia acro IS11S + GARMIN Hart rate monitor」、などを見るとIS11Sにハードウェア的にANT+機能があることは間違いないと考えてよさそうだ。なぜうまくいかないのかわからないが、実際に心拍計と併用するのはX10 Miniのつもりだったので深入りしないようにする。一応接続に失敗した時のログは取ってみたので、この記事の末尾に付けておく。

これでわかるように、ANT+では1対多の通信が可能な模様。というか、既にペアリング済みの受信機が複数あるときに、特定の1台だけに送信する、ということはできないんじゃないか。もっとも実装を考えればこちらの方が簡単なんだろうが。

WikipediaのANT+のエントリ内の “ANT+ Plugins on Android”のセクションには以下の記述がある：

The ANT+ Plugins also feature multi-app concurrency, where any number of apps may have access to the same data coming from the same sensor simultaneously, and any number of phones/devices may read data from the same sensor simultaneously. This opens additional use cases such as always-on background monitoring for multiple apps or group training, and further reduces the burden on developers by helping to ensure them access to device data no matter which apps may be running at the moment.

しかし自分が試した範囲では、同じAndroid端末内では、受信を受けられるのは1アプリに限られるようだった。つまり、何かのアプリが心拍数データを受信している状態で、同じ端末上の他のアプリに心拍数データを受信させようとすると、「ANT+チャネルが使えない」といったエラーが表示され、場合によっては「無理やりこちらに奪うか？」というようなメッセージが表示された。これはGBベースのX10 Miniでの話なので、それが関係しているのかもしれない。その他のバージョンのAndroidの端末では試していない。

 

以下、「ほなみん化」したXperia Acro IS11Sで、心拍計に接続できなかったときのログ。

---- Jun 28, 2014 2:02:57 PM ----
06-28 13:46:36.257   349   657 I ActivityManager: START {cmp=com.dsi.ant.plugins.antplus/.utility.db.Activity_PluginMgrDashboard} from pid 4322
06-28 13:46:38.577   349   618 I ActivityManager: START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.dsi.ant.antplus.pluginsampler/.Activity_Dashboard} from pid 690
06-28 13:46:38.657   349   349 I ActivityManager: Start proc com.dsi.ant.antplus.pluginsampler for activity com.dsi.ant.antplus.pluginsampler/.heartrate.Activity_SearchUiHeartRateSampler: pid=4355 uid=10142 gids={}
06-28 13:46:39.907   349   657 I ActivityManager: Start proc com.dsi.ant.service.socket for service com.dsi.ant.service.socket/com.dsi.ant.service.AntRadioService: pid=4371 uid=10137 gids={3003}
06-28 13:47:03.047  4355  4355 E ActivityThread: Activity com.dsi.ant.antplus.pluginsampler.heartrate.Activity_SearchUiHeartRateSampler has leaked ServiceConnection com.dsi.ant.plugins.antplus.pccbase.AntPluginPcc$2@2bef2db8 that was originally bound here
06-28 13:47:03.047  4355  4355 E ActivityThread: android.app.ServiceConnectionLeaked: Activity com.dsi.ant.antplus.pluginsampler.heartrate.Activity_SearchUiHeartRateSampler has leaked ServiceConnection com.dsi.ant.plugins.antplus.pccbase.AntPluginPcc$2@2bef2db8 that was originally bound here
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.plugins.antplus.pccbase.AntPluginPcc.bindAndRequest(AntPluginPcc.java:638)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.plugins.antplus.pccbase.AntPluginPcc.requestAccess_Helper_SubMain(AntPluginPcc.java:549)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.plugins.antplus.pccbase.AntPluginPcc.requestAccess_Helper_Main(AntPluginPcc.java:522)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.plugins.antplus.pccbase.AntPluginPcc.requestAccess_Helper_SearchActivity(AntPluginPcc.java:367)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.plugins.antplus.pcc.AntPlusHeartRatePcc.requestAccess(AntPlusHeartRatePcc.java:197)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.plugins.antplus.pcc.AntPlusHeartRatePcc.requestAccess(AntPlusHeartRatePcc.java:246)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.antplus.pluginsampler.heartrate.Activity_SearchUiHeartRateSampler.requestAccessToPcc(Activity_SearchUiHeartRateSampler.java:31)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.antplus.pluginsampler.heartrate.Activity_HeartRateDisplayBase.handleReset(Activity_HeartRateDisplayBase.java:90)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.antplus.pluginsampler.heartrate.Activity_HeartRateDisplayBase.onOptionsItemSelected(Activity_HeartRateDisplayBase.java:389)
06-28 13:48:12.634   349   613 I ActivityManager: START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.dsi.ant.antplus.grapher.heartrate/.HrGrapherActivity} from pid 690
06-28 13:48:12.934   349   619 I ActivityManager: Start proc com.dsi.ant.antplus.grapher.heartrate for activity com.dsi.ant.antplus.grapher.heartrate/.HrGrapherActivity: pid=4427 uid=10141 gids={}
06-28 13:49:38.824   349   360 I ActivityManager: Process com.dsi.ant.plugins.antplus.managerlauncher (pid 4322) has died.
06-28 13:49:40.824   349   574 I ActivityManager: Process com.dsi.ant.antplus.pluginsampler (pid 4355) has died.
06-28 13:49:40.824   349   574 I WindowManager: WIN DEATH: Window{2bfc9468 com.dsi.ant.antplus.pluginsampler/com.dsi.ant.antplus.pluginsampler.Activity_Dashboard paused=false}
06-28 13:49:51.124   349   574 I ActivityManager: Process com.dsi.ant.plugins.antplus (pid 4334) has died.
06-28 13:50:08.654   349   657 I ActivityManager: Process com.dsi.ant.service.socket (pid 4371) has died.
06-28 13:53:20.285   349   574 I ActivityManager: START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 pkg=com.dsi.ant.plugins.antplus.managerlauncher cmp=com.dsi.ant.plugins.antplus.managerlauncher/.PluginManagerLauncher} from pid 690
06-28 13:53:20.485   349   619 I ActivityManager: Start proc com.dsi.ant.plugins.antplus.managerlauncher for activity com.dsi.ant.plugins.antplus.managerlauncher/.PluginManagerLauncher: pid=5401 uid=10139 gids={}
06-28 13:53:20.705   349   359 I ActivityManager: START {cmp=com.dsi.ant.plugins.antplus/.utility.db.Activity_PluginMgrDashboard} from pid 5401
06-28 13:53:20.825   349   657 I ActivityManager: Start proc com.dsi.ant.plugins.antplus for activity com.dsi.ant.plugins.antplus/.utility.db.Activity_PluginMgrDashboard: pid=5413 uid=10138 gids={}
06-28 13:53:26.185   349   613 I WindowManager: WIN DEATH: Window{2c69d9a0 com.dsi.ant.antplus.grapher.heartrate/com.dsi.ant.antplus.grapher.heartrate.HrGrapherActivity paused=false}
06-28 13:53:26.185   349   614 I ActivityManager: Process com.dsi.ant.antplus.grapher.heartrate (pid 4427) has died.
06-28 13:53:26.195   349   614 W ActivityManager: Scheduling restart of crashed service com.dsi.ant.antplus.grapher.heartrate/.HrCollectorService in 5000ms
06-28 13:53:31.315   349   371 I ActivityManager: Start proc com.dsi.ant.antplus.grapher.heartrate for service com.dsi.ant.antplus.grapher.heartrate/.HrCollectorService: pid=5430 uid=10141 gids={}
06-28 13:53:33.065   349   359 I ActivityManager: START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.dsi.ant.antplus.grapher.heartrate/.HrGrapherActivity} from pid 690
06-28 13:53:33.905   349   618 I ActivityManager: Start proc com.dsi.ant.service.socket for service com.dsi.ant.service.socket/com.dsi.ant.service.AntRadioService: pid=5450 uid=10137 gids={3003}
06-28 13:53:46.155   349   619 I ActivityManager: START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.dsi.ant.plugins.antplus.managerlauncher/.PluginManagerLauncher} from pid 690
06-28 13:53:46.465   349   349 I ActivityManager: START {cmp=com.dsi.ant.plugins.antplus/.utility.db.Activity_PluginMgrDashboard} from pid 5401
06-28 13:53:48.275   349   574 I ActivityManager: START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.dsi.ant.antplusdemo/.ANTPlusDemo} from pid 690
06-28 13:53:48.525   349   618 I ActivityManager: Start proc com.dsi.ant.antplusdemo for activity com.dsi.ant.antplusdemo/.ANTPlusDemo: pid=5472 uid=10140 gids={}
06-28 13:54:10.155   349   657 I ActivityManager: START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.dsi.ant.antplus.pluginsampler/.Activity_Dashboard} from pid 690
06-28 13:54:10.645   349   561 I ActivityManager: Start proc com.dsi.ant.antplus.pluginsampler for activity com.dsi.ant.antplus.pluginsampler/.Activity_Dashboard: pid=5495 uid=10142 gids={}
06-28 13:54:18.145   349   561 I ActivityManager: START {cmp=com.dsi.ant.antplus.pluginsampler/.heartrate.Activity_SearchUiHeartRateSampler} from pid 5495
06-28 13:56:09.195   349   359 I ActivityManager: Process com.dsi.ant.antplus.grapher.heartrate (pid 5430) has died.
06-28 13:56:09.195   349   359 W ActivityManager: Scheduling restart of crashed service com.dsi.ant.antplus.grapher.heartrate/.HrCollectorService in 5000ms
06-28 13:56:09.805   349   561 I ActivityManager: Process com.dsi.ant.plugins.antplus.managerlauncher (pid 5401) has died.
06-28 13:56:10.915   349   349 I ActivityManager: Process com.dsi.ant.antplus.pluginsampler (pid 5495) has died.
06-28 13:56:10.915   349   349 I WindowManager: WIN DEATH: Window{2c0355a8 com.dsi.ant.antplus.pluginsampler/com.dsi.ant.antplus.pluginsampler.Activity_Dashboard paused=false}
06-28 13:56:10.925   349   587 I WindowManager: WIN DEATH: Window{2c26dbf8 com.dsi.ant.antplus.pluginsampler/com.dsi.ant.antplus.pluginsampler.heartrate.Activity_SearchUiHeartRateSampler paused=false}
06-28 13:56:10.925   349   390 I WindowManager: WINDOW DIED Window{2c26dbf8 com.dsi.ant.antplus.pluginsampler/com.dsi.ant.antplus.pluginsampler.heartrate.Activity_SearchUiHeartRateSampler paused=false}
06-28 13:56:14.225   349   371 I ActivityManager: Start proc com.dsi.ant.antplus.grapher.heartrate for service com.dsi.ant.antplus.grapher.heartrate/.HrCollectorService: pid=5628 uid=10141 gids={}
06-28 13:56:39.805   349   613 I ActivityManager: Process com.dsi.ant.antplusdemo (pid 5472) has died.
06-28 13:56:42.885   349   587 I ActivityManager: Process com.dsi.ant.plugins.antplus (pid 5413) has died.
06-28 13:57:42.015   349   613 I ActivityManager: Process com.dsi.ant.service.socket (pid 5450) has died.
06-28 13:58:55.283   437   437 E wpa_supplicant: Unsupported command: SETSUSPENDOPT 0
06-28 14:00:06.783   349   619 I ActivityManager: Start proc com.dsi.ant.antplus.pluginsampler for activity com.dsi.ant.antplus.pluginsampler/.heartrate.Activity_SearchUiHeartRateSampler: pid=6062 uid=10142 gids={}
06-28 14:00:07.733   349   359 I ActivityManager: Start proc com.dsi.ant.plugins.antplus for service com.dsi.ant.plugins.antplus/.heartrate.HeartRateService: pid=6078 uid=10138 gids={}
06-28 14:00:08.333   349   360 I ActivityManager: Start proc com.dsi.ant.service.socket for service com.dsi.ant.service.socket/com.dsi.ant.service.AntRadioService: pid=6094 uid=10137 gids={3003}
06-28 14:00:08.593   349   384 I ActivityManager: Displayed com.dsi.ant.antplus.pluginsampler/.heartrate.Activity_SearchUiHeartRateSampler: +1s847ms
06-28 14:00:20.333   437   437 E wpa_supplicant: Unsupported command: SETSUSPENDOPT 0
06-28 14:00:20.663   437   437 E wpa_supplicant: Unsupported command: SETSUSPENDOPT 0
---- Jun 28, 2014 2:02:57 PM ----

台湾ROMを積みドコモXi SIMカードを挿したHTC J ISW13HTからSMSを送信する

自分のメイン端末のHTC Jは台湾ROMではXi SIMカードを使っている場合、普通の方法でSMS送れない。このことは「ISW13HT HTC J、Sense4.1ポートROMについて (HTC速報Dev)」で、このROMを編纂した方本人が書いておられる。ソフトバンクSIMカードなら問題ないようで癪だ。

そのページにコメントの中にも書いたが、Beyond SMSというアプリ（XDAでのスレッド）を使えば可能。単なる「ドコモ以外のスマホからドコモのSIMでSMS送信をすると失敗するようだが”validity period ”を設定可能なSMSアプリなら送信できるようだ」の受け売り。ただ、Beyond SMSはSMSアプリの置き換えを意図しているわけではなく、プログラム的に操作しようとすると（例えば特定のイベントで自動的にSMSを発信する、など）簡単ではない。

さて、最近Xposedを試しにインストールしてみたときに、XposedのモジュールにXposedSendRawSMSというのがあるのを知った。これは、かつてはAndroidのAPIの一部であったsendRawPduを使用するもので、それはBeyond SMSと同じ。sendRawPduはその後のAndroidのバージョンで廃止されてしまったようなのだが、一部Androidデバイスのモデルでは、製造会社が意図的に残しているらしい。自分のHTC Jはたまたまそういう端末であったため、Beyond SMSが使える。つまり、XposedSendRawSMSも使える可能性が大。

XposedSendRawSMSの中身を見てみると、核となるのはModSmsMessage.javaのようだ。リフレクションを使ったコードなんて久しぶりに見た。XposedSendRawSMSは、sendRawPduのパラメタを自由に設定した上でSMSを送れるようにするのがその目的だが、自分の場合そんなことはできる必要はなく、validity periodを決め打ちで変更できればいいだけ。なので、XposedSendRawSMSをいわば機能縮小したモジュールを作成すれば、普通のSMSアプリを使って、普通にSMSの送受信ができるようになるのではないか。

以下参考：

• Online PDU Encoder and Decoder
• SMS Messaging
• SMS PDU mode
• Development Tutorial

 

 

HTC J ISW13HTにXposedを導入してみた

HTC J ISW13HTに台湾ROMを焼きさらにWCDMA (UMTS)化をしてドコモのネットワークで使っている。自分の用途には十分なパフォーマンスで概ね満足しているが、電池の管理には少し不満があった。通知エリアに表示されるピクトグラムではまだそこそこ電池に残があるように見えていても、突然「あと9%です」とかいう通知があって、手を打たないと、と思うまもなくシャットダウンしてしまう。ピクトグラムではなく、はっきり残量をパーセント表示で見たい。

Xposedというルート化済み端末向けのカスタマイズ機構で実現できそうだ、と考えて、以下を参照にやってみた。

• Xposed モジュール まとめ
• [FRAMEWORK ONLY!] Xposed – ROM modding without modifying APKs (2.6.1)(20.05.2014)

Frameworkをインストールして初期化した際、Segmentation faultが起こる、ということで、busyboxバイナリを含むインストーラーで再度インストールすることを求められた。

さて、Xposed Module Repositoryを見たりしながら自分の用途に使えそうなモジュールをインストールして試してみたが、うまくいくものがなかなかない。モジュールはJelly Bean以降を対象としていることが多いようで、ICSのこのROMには適用できないのかもしれない。

そこそこ時間を費やして試しまくり、やっと目的を達成してくれたのは、Ex-Themer[ICS/JB][ A Warehouse Of Android Themes ]。

が…数字表示の数字が小さくて読みにくい…。てか、読めない。ああ、嫌だよ老眼、激しく嫌。

結局、XBatteryThemerという普通のアプリを使うことにした。しかも、その後、SDカードの問題でシステムの初期化をしなくてはならなかったので、Xposedフレームワーク自身今は全く使わない状態になってしまった。

参照：

• Collection of Xposed Modules on XDA Developers

DLNA/UPnP AV DMSs and Playlists

Yet another old and only-half-finished article, which I am publishing anyway. On the topic, I ended up using Playlist Creator on the file system from which our primary DMS serves its contents. Using relative paths, of course.

---

It turns out that the DLNA/UPnP AV standards do not provide systematic support for server-side playlist management, which I find utterly surprising. Aren’t there obvious needs for that?

Some DMSs pick it up if there’s a playlist file while scanning their media libraries in file systems, but there does not seem to be any predefined protocol through which you can manage playlists; you can only do that on the file system you are exposing to DMSs. For example, here is a way to do it for MiniDLNA servers. Also, here’s a list of playlist creation tools.

Some DMPs, DMRs and DMCs do support playlists, but not in a collaborative way. Normally those playlists are never propagated elsewhere and stay isolated, confined only inside that particular device/app.

If they should be propagated at all, that happens only between, say, a DMS and a DMC that are designed to work together from the get-go, but not between other devices/apps. Since there is no support for it from the DLNA standards themselves, the interoperability does not exist.

That is why I was very much intrigued by BubbleUPnP Server. It is not a DMS by itself, but it works as a proxy to existing DMSs and provides additional functionality, such as transcoding and remote access.

I am sure some would consider it useful enough for those additional benefits, but I was more interested in the fact that it can also create an OpenHome compliant renderer, acting as a proxy to an existing DMR .

I’ll be honest here — I am not still quite sure what OpenHome is. My first impression was that it is a home automation framework (on a related note, I wrote “Home Automation Systems and Intercoms” before). iControl Networks does present it that way. At any rate, OpenHome includes an arm on home media management called OhMedia, which supposedly addresses the flaws of the UPnP AV standard. Each of the claims seems legitimate, but my take on it is that they should be addressed by augmenting the UPnP standard, not by creating a separate standard. At any rate, OhMedia offers the playlist management functionality, and that is the additional benefit you get by creating a OpenHome compliant DMR with BubbleUPnP Server.

Initially, I thought that was exactly what I wanted, but then realized it wasn’t. The server maintains playlists on its side on the per-renderer basis. Is this what people normally want? Don’t we rather want playlists that are not bound with a particular renderer?

Sure, since you can start playing a playlist on a renderer and then switch the renderer midway, you could potentially create playlists for a “catch-all” renderer and use its playlists as “renderer-unbound” playlists. But I find this solution conceptually unnecessarily complicated and methodically awkward. (I’d also think the initial renderer needs to be present at all times for this scheme to work.)

So, okay, the verdict is in: BubbleUPnP Server is not for me. At least with regards to the server-side playlist management, that is. I might use it for its transcoding and remote access capabilities.

The other option I considered is Twonky Server (Packet Video’s explanation of Twonky Server) combined with Twonky Manger.

You can create playlists with Twonky Manager running on your Windows PC or Mac (no Linux) for Twonky Server. Those playlists will be shown on your DMC/DMP in a Playlists folder. If you are running Twonky Server on a Windows PC, the playlists made on that PC in Windows Media Player will be shown alongside.

The fact

The Android app Twonky Beam’s UI is not quite user friendly. It does not allow playing videos on an external player, thus limiting the codecs it can handle.

In the Windows version, those playlist data are stored at a specific place. Since Twonky Server offers WebDAV access, I wonder why you cannot just place those playlist files directly in such a way that those playlists can be utilized even when the media contents are served by other servers.

One interesting feature of Twonky Server is to aggregate media content from other DLNA servers. I was surprised to learn that it can download DTCP-IP mpegs from the over-the-air digital TV tuner with recording capabilities.

Comparison of UPnP AV media servers

Universal Media Player, derivative of PS3 Media Server

 

Android端末でApp2SD機能によりSDカードに追いやったアプリが消えたり現れたり

先週末にはまった話。

自分のメインのAndroid端末でそのApp2SD機能によりSDカード（厳密にはmicro SDHCカードだがここでは簡単に「SDカード」と呼ぶことにする）に追いやったアプリが消えたり現れたりする、という現象が起こるようになった。再起動で解消することもあれば、そうでないことも、という状態。

件のSDカードは2つのプライマリ・パーティションに分けてあった。第1パーティションはFAT32でフォーマットしてあり、Androidからは普通の外付けSDカードはカードの扱い。2つ目のパーティションはExt4でフォーマットしてあり、Link2SD用に使っていた。

最初は、SDカードのマウントそのものに失敗していると思い込んでしまった。実は第2パーティションは問題なくマウントされてLink2SDによりそこに格納されたアプリは使えていた。第1パーティションも全くマウントされないのではなく、App2SD機能でSDカードに追いやったアプリを格納する/mnt/asec以下がダメなだけで、それ以外の普通のファイルは問題なくアクセスできた。

このしょっぱなの現状把握の段階で誤ってたので時間をだいぶ浪費した。これに気づく前に、たまたま用意していてた新しいSDカードに総入れ替えして置き換えてみたが同じ症状だった。

App2SDの動作の仕組みとか調べてみたが（簡単な説明、もう少し詳しい説明（ディレクトリ名などは古い））、だからどういう原因でこういう現象が起きていて、どう対処すればいいかまでわからない。Link2SDは動作していたので、App2SDはもう使わないようにして全てLink2SDにしてもよかったが、気持ち悪いので以前この問題が起き始める前にCWMリカバリーでバックアップしていたデータをリストしたが /data がリカバーできないというエラーが出る。これは想定外。何のためのバックアップかわからない。

もうしょうがなくROMの焼き直しで初期化。

Link2SD用の第2パーティションはそのまま。つまり、初期化してもそのパーティションは削除されないので、その後Link2SDをインストールして、（ルート化が必要だが）それによりしかるべきマウントスクリプトを導入すれば、それらアプリはすぐ再使用できるようになる。第2パーティションにAPKがあっても、Link2SD自身が認識できていないとそれに相当するアプリは使えないので、Link2SDのオプションの「全てのアプリを再リンクする」を選択し、その後再起動すればその後それらアプリは使えるようになる。

ただ、無料版のLink2SDではアプリの内部データまではSDカードに移せない。なので、上記のようにして、初期化後も以前のアプリが使えても、肝心の設定データ等が失われてしまう。有償のLink2 SD Plusを購入すれば、内部データまではSDカードに移すことが可能になる。予めそうしておけば、今回のように初期化を経ても、設定データ込みで以前のユーザーアプリがすぐ使えるようになるはず…と期待している（未確認）。

しかし、何が悪かったのかわからないが、また最初の問題が発生するようになってしまった。

ここで、App2SDによりSDカードに移されたアプリが格納されている/sdcard/.android_secureディレクトリの名前を、ものは試しでリネームしてみた。Android OSが立ち上がっている状態ではこれはrootでもマウントを解除したりしなければできないので、CWM Recoveryで/sdcardをマウントをした状態でadb shellでroot権限にて行った。その後端末を立ち上げると、システムが自動的に/sdcard/.android_secureを作成するのだが、その上でApp2SDを行うとうまく行っているように見える。

ちなみに、初期化してしまったのでTitanium Backupから取ってあったバックアップをリストアしようとした。そのため、Titanium BackupをPlayストアから再インストールしようとしたが、何度試そうと「容量が不足」エラーでインストールできなかった。結局、/data/以下に元々はLink2SDが作ったと思われるシンボリックリンクが残っていたのが原因で、これを削除すると無事再インストールできた。その他の一部アプリに関しても同様の状態になっていたので、久しぶりに書いたスクリプトでこれら無効なシンボリックリンクを削除すると、問題なくリストアできた。

今は、アプリのSD移動は基本Link2SDでExt4の第2パーティションに移すことにしている。その上でテストを兼ねて、使えなくなってもすぐには困らないようなアプリをAndroidネイティブのApp2SD機能でFat32の第1パーティションに移している。その後数日経つが、今のところ安定して動作しているようだ。

考えてみると、この問題が起こっているときは、端末が異様に熱くなっていた。App2SD機能の実現には複数のmountが使用されているが、これが何らかの理由でうまくいかず、何度もリトライでもしていたのだろうか。

モバイルPSTNのPBX収容

最近、携帯回線での発信が定額、というサービスが出てきている。これがPBXに収容でき、trunkとして利用できれば非常に使い勝手がよいだろう。

その携帯回線用のスマートフォン単独でこのブリッジが実現できれば理想的だが、自分が知る限り簡単にそれが実現できる方法はない。あればこのようなコーダー公募はないだろう（それにしても、予算$250 – $750なんて無茶苦茶）。

なので、自前でPBXを運営し、しかるべきセットアップをする必要があろう。パッと調べてみると同じようなことを考える人はいていろいろ見つかった。

GoIPなるデバイス（紹介記事）。Aliexpressでもいくつかモデルがある。残念ながらどれもGSMのみに対応のようで、日本では使えない。VoIP-Info.orgには同様の機器のリストがある。その中でGemproという台湾の会社の製品が面白い。そのeBayのストアではGP-710という電話端末とBluetoothで接続するタイプのものが$170. モバイル網との通信はBluetooth接続する電話端末の機能次第なので、それがUMTS (WCDMA)をサポートしていればそれが使える。

追記：Siemens Business Comm Gigaset One S30853 H1135 R301 Bluetooth Gatewayなんてのがある。$70程度だからこの手のものにしては最も安いのではないだろうか。

「電話革命-写真編」でPORtechのMV-370という機器が紹介されている。これは単独でUMTS通信機能を持つ。PORTech VoIP GSM Gateways,SIM Server,SIM Bank,E1 GSM Channel Bank,SMS Gateway,SMS Server,IP Speaker,3 way conference box,GSM VoIP Terminal,3G VoIP Gateway,UMTS SIP Gateway,VoIP CDMA Gateway,GSM Fixed Wireless Terminal,sim array,VoIP Adapter ATA–VoIP GSM GatewayによるとCDMA2000対応版もある模様。設定方法。eBay.comで見ると、$275（送料別）で、やはりGP-710の方が安い。もっとも別途Bluetooth対応の端末が必要になるが、それは一台くらい転がってるものだろう。

Asterisk用Chan_dongleモジュール。Huaweiのドングルを使うものでこれは3GもOK。Chan_mobileでBluetooth端末と接続。

2005年以降更新のないMiax: Mobile IAX。OpenWrtではリポジトリからすぐインストールできる。Inter-Asterisk eXchange – Wikipedia, the free encyclopedia。

FreeSWITCHであれば、GSMopenというモジュールで実現できそうだ。MobiGaterというGSMopenと併用することを前提にしたハードウェアもある（Asteriskとの併用も可）。Bluetoothで接続した携帯端末を利用するというmod_handsfreeという非公式のモジュールがある（ただし古い）。GSMOpenでBluetoothが利用できた、というコメントもある。参考：HFP for Linux is a Bluetooth Hands-Free Profile server。

OpenBTS (Wikipedia)。上のAsterisk、FreeSWITCH専用のモジュールではなく、Asterisk, FreeSWITCHなどのPBXシステムから利用できるよう独立したもののようなもの？GSM専用のように思えるが、UMTS（日本ではWCDMA）についての言及もあるので、それもサポートしているかも。関係ない？

Bluetooth対応の携帯電話（スマートフォンでなくても構わない）とAsteriskをChan_MobileというモジュールでBluetoothで接続させる。すご…。

番外：

SIPではないが、GSMとSkypeとのブリッジ。モデムから得られる音データではなく、ヘッドセットジャックからの出力を利用するという執念を感じさせる力技。

Skypeというと以前はSIPとのブリッジに興味があった。もうあまり必要性を感じてないが、Ippiの無料のUnlimited 5というプランは、SIPからSkypeやHangoutsへのブリッジをサポートするようで、それはそれで面白いかも。ただ、条件つきの無料かもしれない。

EZCastが届いた

パチもん感バリバリのパッケージ

とはいえなかなか洒落てはいる

注文していたChromecastクローンのEZCastが届いた。以下、自分の感想・メモだが、あくまで自分用であり、他の紹介記事に出ているようなことはばっさり省略しているので、ご覧になる方はそのつもりで。これだけ読んでも、全体像はわかりませぬ。

EZCastデバイスが自宅LANにwifi接続できるよう、手元のAndroid端末上のEZCastアプリでセキュリティーキーを入力する必要があるのだが、Google日本語入力を使っていると、ソフトウェアキーボードのキーを押すたび、その前に入力された文字が消去された。一時的にデフォルトのキーボードに替えることでしのいだ。

給電用USBケーブルはwifiアンテナも兼ねている模様。使用中結構暖かくなる。

EZCastデバイスを使用とするデバイス（仮にクライアント・デバイスと呼ぶ）は、直接それにwifi接続する。そのEZCastデバイスは無線LANルータにwifi接続する。クライアント・デバイスがLAN、あるいはインターネットに接続するにはEZCastデバイスを経由する、というのが基本の使用形態。対してChromecastの場合は、クライアント・デバイスとChromecastとはセットアップ時のみ直接wifi接続し、その後は一般的IPデバイス同様、二者はルーターを介して接続するようになっていると理解している。

EZCastデバイスを使用とするデバイスには自宅LANのサブネットとは別のサブネットのIPアドレスが振られる。自宅LAN内のデバイスは見えない（例えば後で出てくるDLNAメディアサーバ）が、インターネットとの間で動作するHangoutsやSIPによるVoIPは問題なかった。

VGAディスプレーを使ってテストするためゴテゴテとアダプタをかます。くたびれた畳が哀愁を誘う。

さて、EZCastデバイスはそうやってインターネットに繋がるなり自動的に自らをアップデートした。失礼ながら中国製品とは思えないまともさ。

それどころが、全般的にきっちり作りこまれていて好感をもった。画面表示は自動的に日本語が選択され、その日本語に違和感もない。ただ、マニュアルには残念感がひしひしと漂う。一度だけでも英語に堪能な人を一人雇うだけで、あまりに頓珍漢な英語は避けられると思うのだが。

ステータスを示すLEDランプがあるのだが、最初壊れて全く点灯していないんじゃないかと思ったくらい、はかない点灯ぶり。まぁ、実害はないが、LEDに対する不満としてはまぶしすぎることが多いことを考えると、ちょっと意外。

先程も述べたように、クライアント・デバイスは通常EZCastデバイスを介してインターネットに繋がる。しかし、その基本の使用形態ではなく、クライアント・デバイスが直接自宅LANに繋がっている状態でも、EZCastデバイスのDMRはアクセスでき、同時に自宅LAN内のメディア・サーバー（DMS）は見えるのでよかった。これができなければ自分としては利用価値は激しく落ちるところだった。

やる気を感じさせない音楽再生画面

とはいえ、音楽を再生させたときの画面のやる気のなさと言ったら…。アルバムアートくらい表示して欲しかった。全般的になかなか完成度が高い製品なので、もう少し頑張って欲しかったところ。

ちなみに、自分が以前CDをリップする際はWMAでエンコードしていたが、これをBubbleUPnPを通じてEZCastデバイスに再生させようとすると、サポートされてないフォーマットだ、といってエラーになる。が、これはBubbleUPnPのSettings -> UPnP Tweaks -> Mime-type checkのチェックを外すことで回避できた。

アカウント登録するのにSSIDの入力も求められる

Windows 7/8 PCからはサブディスプレーとして使えるようだ。このYouTubeビデオの4:08過ぎから、それを行っている様子を見ることができる。自分も試そうと、Windows用クライアントソフトをダウンロードしようとしたら、iezu.comでアカウント登録を求められた。そのときに電子メールアドレスだけでなく、EZCastデバイスのSSIDの入力も求められたのにはちょっと感心した。機種ごとのIDの役割を果たしているのであろう。

さて、自分のメインのデスクトップPCで試してみると、EZCastデバイスにwifiで接続できることが要件のようで、その機能のない我がPCでは無用の長物となってしまった。

自分としては、EZCastデバイスを利用するためには、クライアント・デバイス上でwifiのアクセスポイントを変えねばならないこと、基本的にあらゆる操作をEZCastアプリを経由して行わなければならないところが煩わしい。Chromecastであれば、wifi設定の変更は必要ないし、アプリ側が対応してさえいれば（例えばビデオ・プレーヤー）、アプリを使用中、「あ、これはTVで見たいな」と思ったら、すぐアプリのキャストボタンでChromecastで再生できる…はず（何せ実物を持ってないので想像）。いちいち、EZCastを立ち上げて、再生していたビデオを再度探して…などという面倒な手続きは発生しない。ただし、上で述べたように、DLNA機能だけであればwifi設定を変えることなく利用できる。

結論としては、もし自分だけが使うという前提ならどうせDLNA機能しか使わないので2,000円強ならまぁありかな、と。最近のTVはスマート化していてDLNA機能などは最初から持っていたりするようだが、そうでないものにこれを挿して、簡単スマート化するのも手だろう。EZCastの方はまだ機能が上がる可能性がある分、あるいは自分でハックできる可能性がある分、扱いやすいとも言える。

最近のAndroid端末にビルトインの基本的なメディア再生アプリには、さりげなくDLNA機能が盛り込まれているように思う。Samsungの端末にはAllShareという名前で、XperiaだとThrowというボタンで、既に端末上で再生中のものを他のDMRに再生させられるようになっている。DMCからメディアをコントロールするより、このようにDMPから行うほうが我々の直感に合っているのではないだろうか。この傾向はChromecastの登場もあってますます加速するだろう。だとすると、EZCastのようなディバイスにも、DLNA機能さえあれば一般人には用が足りるんじゃないかと思う。もっとも、アプリ（製作者側）の都合でそうされたくないもの（例えばVODアプリ？）を無理やりTVで見るためにはミラーリングが有用かもしれないが。

いずれにせよ、これはそもそもiOSデバイス（具体的にはiPad）ユーザ向けのプレゼントとして用意したもの。EZCastのAirPlay機能を利用するなら、Chromecastと同様の使い勝手が得られると期待している。ただ、それでもwifiのAPを替えなければならない、というのはいただけない。←これは自分の誤解で、iOSデバイスとAirPlayを介して利用する際には、最初のセットアップ時以外直接iOSデバイスからEZCastにwifi接続する必要はない。それぞれがルーターにwifi接続し、ルーターを介して間接的に接続する形態で利用できる。

物理的な設置については、”EZCastの設置を試みた“をご覧あれ。

Android端末から他のAndroid端末への通話とSMSの転送

2014年以前に書いてた記事。完成していないが公開。

---

以下の話で、現在自分のメイン端末のHTC J ISW13HTは台湾ROMではXi SIMカードを使っている場合普通の方法でSMSを送れない。が、ちょっとだけプログラムを書いてXposedモジュールを作れば、普通にSMSの送受信ができる可能性が高いと踏んでいる。それができる、という前提の話が以下。

---

前提

• 主端末 HTC J ISW13HT 台湾 ICS ROM+WCDMA化 – 主回線
• 副端末 X10 Mini Mini CM7 (GB)  – 副回線

どちらにもドコモのSIMカードが刺さっている。また、双方とも単独ではデータ通信はできないのが前提。外出時データ通信は別のモバイルルーターでまかなっているがデータ通信が常時できるという前提は置かない（というより、自分の意図云々は別にして、現実的に置きようがない）。

また、副端末に刺さっているSIMカードは本来は父用だったもの。なので、主端末の自分用回線（以下、主回線）と副端末の父用回線（以下、副回線）との間にはファミリー割契約が存在し、そのためこれら2回線間での通話は常時無料。ただしSMSについては費用発生。

主目的

主端末に割り振られている電話番号宛のi) 通話、と ii) SMSをサブ端末でも受けられるようにする。主端末は常用しており常時電源を入れているが、副端末は使うときにしか電源すら入れていないことが前提（この間主端末の電源をどうするかは後述）。

この転送は副端末が電源を入れているときだけ起こるのが望ましい。しかもそのときはいつも、ではなく、そのときどきで転送を行うかどうか選択できるのが望ましい。

副目的

主回線宛の電話は、主端末が圏内にあり電源が入っている状態であっても、着信できないことがある。このような場合、今までは単にその留守番電話サービスで伝言を受けていたが、VoIPに転送させることでそのときに着信して通話できるのが望ましい。

自宅はどうもドコモのいくつかのアンテナの受信エリアのちょうど境目にあるようで、端末の物理的位置が全く変わってなくても、接続してるアンテナが結構な頻度で変わっている。しかも、プラスエリアのアンテナと、そうでないアンテナとの切り替わり、いわゆるハード・ハンドオーバーがうまくいってない気がしている。なぜなら、その後一見繋がっているように見えても、発信、受信ともできないことが起こるから。

転送でんわサービスと留守番電話サービスとの干渉

メイン端末、サブ端末双方の回線で現在留守番電話サービスを使用している。ドコモの転送でんわサービスのページにあるPDFマニュアルには以下の記載がある（最終ページ）：

他のサービスとの併用： ●留守番電話サービスと併用してご利用いただいている場合、転送でんわサービスか留守番電話サービスのいずれかを開始すると、他方は自動的に停止となります。また、現在サービス中のものを停止にしても、他方は自動的に開始になりません。

この非対称性は注意すべきだろう。

なお、転送先（今想定しているシナリオではサブ端末）が話し中の際、転送元（同じく、メイン端末）の留守番電話サービスで伝言を受けるように設定できる（マニュアル p. 9）。自分の想定しているシナリオでは、転送先（サブ端末）の留守番電話サービスで伝言を受けられた方が都合よいように思える。が、転送でんわサービスについて他の電話機（例えばサブ端末）からの遠隔操作 もできる（マニュアル）ので、転送元（メイン端末）の留守番電話サービスで伝言を受けてもサブ端末から聞くことは可能。

これは転送先が話し中の場合に限り、電源を切っている場合は別扱いの模様。転送先が話し中、という極めて珍しい状況のためだけに、転送元に留守番電話サービスを残すのは賢明か？ そもそも、サブ端末のSIMカードはもともと父の回線用であるが、その留守番電話サービスはもう止めてしまってよいであろう。その番号宛の電話は現実には全くかかってきていない。もしかかったとしても電源が入っていない間のものについてはドコモがSMSで番号を通知してくれるので、かかってきたということがわからないということはない。

ただし、このようにした場合、メイン端末の回線で伝言を受けたときに、メイン端末にはSMSで通知があるが、サブ端末には通知がない。これはメイン端末からサブ端末に何らかの手段で通知させる必要がある。ただ、ここではSMSの転送も想定しているので、それで自動的に通知できる。

考察

まず、通話はさておき、SMSの転送がリアルタイムで行われることが要件なら、転送状態の間もメイン端末の電源は入ってなければならない。通話の転送はキャリア（ドコモ）側で行われるが、SMSの転送は端末側でやらなければならないから。 SMSプロキシのようなアプリを使えばよいように思えるが、このまま使うと常時転送されてしまう。もっとも自分の場合、そもそもメイン端末でもSMSを滅多に受け取らないし、SMS送信に費用がかかるといっても一通3円とかだから、大きな問題にはならない。

注意しなければならないのは、本来のSMSの送信元もSMS転送時に含めなければならないこと。SMSプロキシにはその機能がある。ただ、元々のSMSが、文字数制限ぎりぎりの長さの場合、転送時に送信元番号も含めた場合、転送後に末尾が欠けるか、エラーを起こして転送できない可能性がある。SMSプロキシアプリの更新履歴を見ると、こういう状況に対処しているように思えるが未確認。

ちなみに、今まで知らなかったがSMS gatewayに分類されるAndroidアプリは結構ある。たいがいはHTTPベースのAPIを提供している。個人用途だとあまり使い道がないように思うが、例えば仕事で顧客にSMSを送ったりシなかったりしなければならないのなら使えるかも。古Android端末の有効な再利用方法にもなりうる。

パブリックなJabberサーバ xmpp.jp

• メイン端末
  • 転送でんわサービスでサブ端末の番号に転送する設定に固定。
  • 転送されるまでの呼び出し時間を、通常時の例えば10秒と、サブ端末だけ持ちだしている間の0秒とで切り替えを行う（電話転送に関して唯一切り替えが必要な部分）。
  • 留守番電話サービスは廃止。
• サブ端末
  • 転送でんわサービスで050の番号に転送する設定に固定。
  • 転送されるまでの呼び出し時間を例えば10秒に固定。サブ端末の電源が入っている間は、メイン端末ではなく、これが自分が持ち歩いているものである、という前提で。
  • 留守番電話サービスは廃止。
• Fusion
  • 留守電サービスは切るか、セイフティーネットとしてオンのままにしておくのなら、留守電サービスが動き始めるまでの呼び出し時間を十分長くして、先にPBXes側の留守電サービス（voice mail service）が動くようにする。

Fusionのアカウントを留守電専用に使えると便利だったが、PBXesでSIP URIへの転送がうまくいかない。PBXesのボイスメール機能でも録音をファイルとしてメールアドレスに送らせるようにできるが、WAV形式。しかも一般的でないコーデックを使用しているらしくRemote Waveというアプリが再生に必要。

PBXesについては、この記事にあるような設定になっていると思われる。結果として、DIDからルーティングされて内線に到達してから、ボイスメールのためのメッセージが流れ始めた段階で”*”ボタンを押すことで、そこからボイスメール・システムにアクセスできて、録音済みのメッセージを聞くことができる。

問題は、PBXesに伝言がある、ということを、データ通信できない状況でのサブ端末が知るすべがないこと。これは、PBXesからの通知メールをメイン端末でモニタし、それがあればそれをSMSでサブ端末に通知するしかない。

1. 直接ドコモ回線で着信することが何らかの理由で2回線分失敗したときに、それでもインターネット電話で（なんとか）受けようとし、

2. そのインターネット電話というのがPBXesの内線1本だけだとする（リソースを節約するためCSipSimpleで1つだけアカウントを生かしておく。つまり、2つ以上にしない）。

そうすると、上でmedia bypassを実現するために、PBXes上でinbound routingでring groupを使用しないのだとすると、もう留守電話はPBXesが用意しているものを利用するしかない。

Ring groupが使えるのなら、別のSIP URIに飛ばすこともできるので、ひょっとするとFusionの留守電サービスが利用できるかもしれないが、以上の前提を全て満たすことが必要なら、それはできない。 決してそう意図したわけではなかったのだが、結果としては「無料で留守電サービスを使う方法」に紹介されている方法と同様の方法となった。もっとも、その記事の目的が留守電サービスを無料にすることであったのに対し、こちらは、たまたま結果としてそうなっただけ。2本の携帯回線間で転送をし、それでもダメな場合は（電波状況が悪いだけで起こりうる）、VoIPに転送しようとしたら、たまたま自分が用意していたVoIPのセットアップにPBXが含まれていたので、その留守電サービスが利用できた、というだけ。

ファミリー割引指定一般電話番号で050番号を予め指定しておくと割引があるのか？

他の副回線の有効な利用方法

どうせ父の回線の契約は簡単には解約できないが2年縛りが存在する。回線維持費は比較的低く抑えられるようになっている。…といった現状の下では、父の回線は2年縛りが終了するまでそのまま維持して、何かに有効利用したほうがよい。ここで考えたのはそういった有効利用方法の1つで、それによってサブ端末のみでも、受信に関しては、通話、SMSともメイン端末と（多少の余分な手間はあっても）同じような使い方ができるようになる。

もう1つ考えられる応用方法がある。それはVoIPとのブリッジに使うこと。 自分の現在の生活スタイルでは、サブ端末を使うときはデータ通信は特に必要ない。具体的には戸外で運動するときにだけ使うので、その間運動モニター用アプリが使えて、緊急電話を受信したり発信したりできればよい。発信の必要はほとんどないとは思うが、何らかの理由で100番、119番通報する必要がないとは言い切れない。

しかし、何らかの理由でデータ通信できるようになったとする。 メイン端末単独でこのブリッジが実現できれば理想的だが、自分が知る限り簡単にそれが実現できる方法はない。なので、自前でPBXを運営し、しかるべきセットアップをする必要がある。例えばFreeSWITCHであれば、GSMopenというモジュールで実現できそうだ。

付記

外出時にはモバイルルーターを使用するようになってから、特に海外からの（しかも仕事がらみの）緊急連絡を受け損ねることを心配しなくて済むようになった。こういう連絡は、国際電話料金が高いため、メールなどインターネットを介した手段で送られてくる。サブ端末のみ持ち出すときには、常時インターネットに接続していないので、やはり問題になる。上のセットアップでは、いずれにせよメイン端末でSMSの転送処理をせざるため電源を入れていなければならないので、同じ端末上で例えば特定のアドレス宛のメッセージも同様にSMSの転送させることが考えられる。

ただ、これはメイン端末でなければできないことではなく、本来はサーバーを用意してそれに担当させるのが望ましい。インターネットのサービスでSMS送信をサポートしているものはいくつもあるし当座はそれでよい。サブ端末だけに送信できればよいのであれば、そのISPをMopera Uとすれば、そのメールサービスではSMSで着信を通知させることができるので（「送信先アドレス、件名、本文の合計最大70文字までお知らせします」）、簡易的な代用案となる。

SPモードメールやドコモメールについてはプッシュ通知についてよくわからない。前者については、通知アプリの動作のしかたから、SMSによる通知で、しかも内容についての情報は全くなしで、単に新着メッセージがあるかどうかが知らされるだけと想像される。同じドコモの留守番電話サービスのSMSによる通知と同様なんではないかと。 が、災害時などにもサーバーからSMS送信をしたいと考えているので、サーバーが直接（SIMカードを刺さしたモデムを利用して）SMS送信できるのが望ましい。そのため、Hanacell「ジャパンSIMカード」を使おうかと思っていたが、SMS一通12セントなのはさておき、価格が以前の$25から$39に知らないうちに上がっていた！

Mopera UスタンダードプランからSPモードへ変更…しなかった

自分はドコモの回線を2本持っている。1本は主回線で音声通信主体。2本はデータ専用回線。あと、父用のが1回線（音声主体）。これら全てでデータ通信のISPとしてMopera Uスタンダードを利用してきた。使用料は月500円であるが、最初の6ヶ月間は無料、というキャンペーンをやっていたから。が、その6ヶ月が過ぎようとしていたのでより安いものに変更しようとした。

もととは、「「mopera U シンプル」プランの提供および「mopera U スタートキャンペーン」お申込み終了について」というのを知り、スタンダードプランの500円から200円（どちらも税抜き）に落とせるのならめでたい、と考えた。しかし、ドコモショップで手続きしようとすると、それはドコモの新料金プランの一環で、シンプルプランを利用しようとすると、新料金プランに切り替えないといけないという。それは自分にはメリットがないので止めて、代わりにMopera Uシンプルプランよりは高いものの、スタンダードプランよりは安いSPモード（300円/月）に変更を依頼した。

これが愚かだった。

ISPとしてSPモードとMopera Uとの違いをよく理解していなかった。特に、SPモードはドコモ端末専用で、IMEIによるふるいわけにより、それ以外の端末からは使えない、ということを知っていなかった。「SIMロックフリー端末をdocomoのSIMカードで利用する方法まとめ！」ぐらい目を通しておけばよかったが、ドコモのSIMカードであれば、ドコモ純正端末であるかないかがISPの選択に影響がある、という発想が全くなかったのだ。なので、一般ドコモユーザ向けの違いの解説を読んでは、ちょっとした機能の違いしかないのか？などと考えていた。

とはいえ、SIMフリーiPhone5でSPモードが使えた（同様の情報）、あるいは、Google Play版Nexus 5でも、という情報もあるにはあるので、XperiaのspモードのAPN情報を参照しながら、ダメ元でメイン端末のHTC J ISW13HTとサブ端末のSony Ericsson Xperia X10 Mini E10iの2機種で試してみた。使用したSIMカードは、Xi用で、当然その回線用にSPモードの契約はしてある状態。

結果はやはり双方の機種でダメ。まぁそうだよな…。

結局元のMopera Uスタンダードプランに戻すことに。ただし、データ専用回線のみで、その他の2回線についてはISP契約を全くしないことにした。普段使うことはなくても、何かの非常事態に単独で（つまりモバイルルーターが使えなくても）データ通信ができるよう、保険をかけられるのに越したことがないのだが、その費用が月500円だと割が合わない、と判断。

ちなみに、このデータ回線契約に付随してDocomo Wifiも利用しているが（自分の契約しているデータプランでは無料なので）、wifiのセキュリティーキーは以前と全く同じだ。考えてみれば激しく当たり前な気も。

さて、このデータ通信用回線については、ドコモのスタッフに、電話でしか情報を確認したり契約の変更したりできない、と説明されたが、それが嘘だということがわかった。My Docomoを利用するにはDocomo IDが必要。Docomo IDの作成には通常認証のためSMS受信が必要だが、SMSが受信できなくても登録する方法がちゃんとWebには記載されていた。言われたことをそのまま真に受けた自分が馬鹿だった。

My Docomoを使えるようにした上で今までの料金を見ると、このデータ通信回線の費用は610円/月だった。これからMopera Uスタンダードプランの費用が追加されるので合計1,100円強になるが、これで月に7GBまでLTEで通信できるのだから悪くなかろう。最近価格競争の激しいMVNOの提供するサービスでも、これに匹敵するのは見当たらない。モバイル・ルーターを別途持ち歩かなくてはならなのだが煩わしいが。

ちなみに音声回線については、月々サポートの額の方が通話料金を除く各種料金より大きいので、事実上無料電話分があるような状態。2年目から基本料金（タイプXi にねん、だったか）の780円/月が課金されるようになるから、そうするとこの無料電話分はなくなるだろう。それでも月300円、とかそういう程度になるはず。

VoIPサービスScydoを試してみた

「世界一安い海外IP電話サービス『Scydo』アプリの使い方」、「『Scydo」　（通話料［１．４円／分］の電話サービス）」、なんかをみて、ScydoというVoIPサービスに興味をもった。何せありえないような安さ。SIPサービスプロバイダという形ではなく、専用のAndroidアプリ、あるいはiOSアプリで利用する形になる。

が、その使用には躊躇した。なぜなら、いわゆるBetamaxクローンと呼ばれている一群のVoIPサービスプロバイダの1つであるから。Betamaxクローンは総じてビジネス面で評判が悪い。たいがいは、一旦クレジットカード情報を渡してしまうと、その後いわれのないチャージをされてしまう、といった苦情だ。

ただ、上記記事を見るとiPhoneアプリではiTunesから支払えるので直接クレジットカード情報 が渡す必要がなく、それならまだ安全だろうと考えた。Androidアプリについてはあまり記載がなかったが、それではきっと同様にGoogle Playから支払うという道が用意されているだろう、と勝手に踏んだ。…が、それは誤りだった。Androidアプリではそのような支払い方法は用意していない。

そこで一計を案じた。この時点で既に自分のAndroid端末でアカウントを作成していたので、知人のiPhoneユーザに頼んで、自分のアカウント情報を教えた上でScydoアプリをインストールしてもらい、それでiTunesでの支払いの代行を頼もう。…が、これも失敗。なぜかそういう支払いの選択肢が提示されないという。

それならば、と一旦既に作ったアカウントを削除することも考えた。ウェブサイトScydo.comのアカウント管理画面では、そのためのボタンが用意されているのだが、何度押そうと何も起こらなかった。

諦めてウェブサイトScydo.comでクレジットカードを使って10ユーロ分のクレジットを購入。ちなみに、アプリでのログイン時には自分の携帯番号として090…や080… のままを使えばよいが、ウェブサイトScydo.com上でログインする際は、先頭の0を落とさなければならない。

実際に使ってみた感想は以下。

このアプリを使って発信すると、アカウント作成時に登録した番号が通知される。どの端末を使っても、だ。SIMカードすら挿さずwifi運用している端末からアプリを使って発信しても、だ。これを詐欺紛いだと感じる人は多いだろう。

ただし、「世界一安い海外IP電話サービス『Scydo』アプリの使い方」にも書いてあるが、ドコモ回線には非通知になってしまう。非通知電話を拒否している人も多いだろうから、これはうれしくない仕様。もっとも、おそらくはこれはドコモ側の事業者としての判断の結果で、その判断自身は正しいと思うが。

上記記事では、通話音質は十分使いものになる、というふうな記載があるが、端末機種によって違いがあるようで、Au携帯電話番号宛に発信してテストしてみると、現在自分のメイン端末のHTC J ISW13HTでは、相手の声はこちらには明瞭に聞こえるものの、こちらの声が相手には聞き取れないほど小さくしか伝わらないらしく、実用にならない。極めて残念。公式アプリを使うしかないのだがマイクの調整のようなことは全くできない。そもそもISW13HTの内蔵マイクがいまいちだというから、そのせいかもしれない。Bluetoothヘッドセットで使えばその問題を回避できるかも、と思ったが、残念ながらそうするとアプリが落ちる。

Scydo.comのアカウント設定画面には”SIP settings”の文字が

その他自分が使える端末で試してみると、通話品質は Xperia Acro IS11S > Samsung Galaxy Note 3 > Xperia X10 Mini の順になるようだ。ただ、最下位のXperia X10 Miniでも、なんとか使えるレベルだというのは嬉しい。このXperia 2モデルには現在SIMカードは挿しておらずwifi運用している。特にAcroに至っては、元々Au用端末だったものにUMTS (WCDMA)用カスタムROMを焼いているので、SIMカードを挿して携帯電話として使うことはもうできない。それでも（仮に詐欺紛いであっても）自分の携帯電話番号を通知して電話をかけることができる。これが役に立つこともあるだろう。

さて、先に述べたように、ScydoはいわゆるBetamaxクローンと呼ばれているものの1つなのであるから内部的にSIPが使われているのは間違いあるまい。ウェブサイトでもちらっと”SIP Settings”と書かれたリンクもある。リンク先にはSIP関係の情報は記載されてないが、なおのことそうではないかと思ってしまう。もしSIPで扱えるのなら自由度がぐっと高くなる。なんとかその情報を抽出できないか。

…というわけで、パケットキャプチャしてみることに。

まずは、Lubuntuをインストールしてあるネットブックで、”Make Your Linux Machine a Virtual Router“で仮想wifiホットスポットを作成し、そこにAndroid端末を接続させる。

コマンドラインで操作するのだが、既に設定が済んでいれば、

• ホットスポット開始はsudo ap-hotspot start
• 停止はsudo ap-hotspot stop
• 起動はsudo ap-hotspot restart

仮想ホットスポットを動かしているネットブックにAndroid端末から2.4GHz帯11nでwifi接続したときの通信速度

ついでにこの状態で端末でスピードテストもしてみた。本編とほとんど関係ない画面キャプチャその2である。

その上でネットブック上でWiresharkを使ってパケットキャプチャしてみた。結果としては、明らかな形ではSIPプロトコルは使われてなかった。まずサイトAとの間で通信があり、次に別のサイトBとの間で通信が行われている。後者はメディア・データの交信であろうから、前者ではセッション管理が行われているのだろうと想像されるが、自分の力では中身は理解できなかった。これは暗号化されているから？

残念！

追記：

ここまでやらなくてはプロトコル解析なんかできないってことですね。ちょっとパケットキャプチャしただでできると思った自分が甘かったです。