iPhone でも Android でも、ほぼフル充電から時間あたりの消費率が徐々に増えてゆきます。
待ち受け状態だけで１日経過（２４時間経過）時点で １.０ %／ｈ ならば、「よし」と思います。
つまり １００ % が２４時間後に残量７５ % 前後ならば問題はないといえましょう。
これ以上の残量ならばバッテリー保ちがよいといえます。
これ以下ならばよくないので、設定等を見直した方がいいかも知れません。
iPhone 8 は非常に保ちがよく、２４時間経過時点で ０.７ %／ｈ 前後です。
搭載バッテリー容量からすると非常に保ちがいいと思います。
iPhone 6s はこれよりは少し保ちがよくなくて、それでも ０.８〜１.０ ％／h ほどです。
Android 機ですが、P10 Lite で ２４時間経過時点で １.０ ％／ｈ です。
P20 Lite は少しよくて、０.９ ％／ｈ ほどです。
以上の数字はソフトフォンアプリとして SessionTalk / Acrobits などのプッシュ型を「プッシュ着信設定」で使用時の数値です。
常駐型にすると iPhone は途端に消費率がハネ上がり、２.５〜３.０ %／ｈ になります。
ですので iPhone の場合はソフトフォンは「プッシュ型」が必須ですね。
Android 機の場合は常駐型でもプッシュ型と少ししか変わらないので、iPhone よりは選択肢が増えます。
ただ、常駐型の中にはもっと消費するものもあるようですから実際に使ってみてご自分が納得できるものをお使いください。
2019-07-23
2019-07-19
プッシュ型と常駐型への同一アカウント登録での奇妙な振る舞い
ブラステルは一つのアカウントを複数台の端末に登録できます（ブラステル社はできることを認めているが非推奨です）。
ところがプッシュ型と非プッシュ型（常駐型）の両方に一つのアカウントを登録した場合、無音問題が発生し、通話不可となる場合があります（このためにブラステル社は非推奨にしていると思われます）。
常駐型同士の場合はこのような無音問題は発生しません。
プッシュ型を含む組み合わせでもすべてのケースで無音問題があるわけではなく、発生したりしなかったりと、不安定な状況なのです。
いったん無音問題が発生した場合、解消のためにはプッシュ型の方の登録を非プッシュにし直し、改めて登録オフ／オン（デアクティベート／アクティベート）することが必要です。
それでも解消しない場合はマイページからパスワード変更してサーバー側の状態をクリアにする必要があります。
どういう状況が NG でどういう条件なら OK になるかを改めて検証してみました。
なぜこのような検証をするかいいますと、iPhone は常駐型ではバッテリー消費が半端なく、プッシュ型が必須だからです。
Android は Doze 機構のおかげで常駐型でもバッテリー消費は抑えられています。
その代りディープスリープ時の不着信問題が発生する可能性があり、これはこれで悩ましいのですが。
プッシュ型として Acrobits / SessionTalk (Pro) を、常駐型として GS Wave を使い、同じアカウントをこれらプッシュ型と常駐型に登録して呼び出し通話確認しました。
そのときのお互いの振る舞いに奇妙なことがあり、整理の意味で状況を記載します。
使った番号は「ブラステル１」と「ブラステル２（イエデン）」です。
受信側のプッシュ型は「プッシュ着信設定」です。
これは「イエデン」を ATA 経由（常駐型と同等）で使える（発着信）と同時に、ワタシのスマホでも使える（発着信）ようにするのが目的です。
これができれば「イエデン」が外でも発着信可能となるのです。
「ブラステル１」は他からかける電話を想定し、発信されたときに「ブラステル２（イエデン）」側がどのようになるのか、という検証です。
「ブラステル１」ではなく携帯電話でもほかの SMARTalk などでもいいのですが、検証で有料通話にしないためにこのようにしました。
うまくいくケースでは携帯電話からの発信時と SMARTalk からの発信時も追加検証しています。
以下の ６つのケースを確認しました。
「受信（着信）」側のプッシュ型は iPhone 8 に設定、常駐型は Android 8 および iPhone 6s で検証しましたが、Android 8 と iPhone 6s で違いはありませんでした。
最終的には常駐型は HT701（ATA）でも検証しています。
【ケース ①】
発信：SessionTalk（ブラステル１）→ 受信：GS Wave （ブラステル２）
SessionTalk（ブラステル２）
このケースでは受信側はどちらも着信はしますが、
音声は送受ともに無音で通話不可です。
【ケース ②】
発信：SessionTalk（ブラステル１）→ 受信：GS Wave （ブラステル２）
Acrobits （ブラステル２）
このケースでは １項と結果は同じで通話不可です。
【ケース ③】
発信：Acrobits （ブラステル１）→ 受信：GS Wave （ブラステル２）
SessionTalk（ブラステル２）
このケースでは問題なくどちらも通話可能です。
【ケース ④】
発信：Acrobits （ブラステル１）→ 受信：GS Wave （ブラステル２）
Acrobits （ブラステル２）
このケースでは受信が Acrobits の方は通話可能ですが、GS Wave 側は着信時に
発信元選択行が２行現れ、どちらを選択するかで一方は通話可能で、他方は通話不可
です（「発信者 ID メソッド」の初期値が「ユーザー ID」であったため）。
さらに細かく発信側の「発信者ID メソッド（※）」を以下の設定にしたときの
GS Wave 側の状況は以下のとおりです。
P-Preferred Identity ： 通話可能
P-Assert Identity ： 通話可能
Remote-Party-ID ： 発信元選択行表示で一方は通話可能／他方は通話不可
From username ：（上と同じ）
選択行表示は「ユーザー ID」または「電番」で「ユーザー ID」の選択で通話可能
設定と動作の矛盾が感じられます
【ケース ⑤】
発信：GS Wave （ブラステル１）→ 受信：GS Wave （ブラステル２）
SessionTalk（ブラステル２）
このケースでは問題なくどちらも通話可能です。
【ケース ⑥】
発信：GS Wave （ブラステル１）→ 受信：GS Wave （ブラステル２）
Acrobits （ブラステル２）
このケースでは問題なくどちらも通話可能です。
以上の状況は受信側 GS Wave の部分を HT701（ATA）にしても同じ結果です。
【ケース ①】と【ケース ②】は着信側のアカウントを片方だけに設定の場合は通話も問題ありません。
プッシュ型が発信し、プッシュ型で着信の場合も複数デバイスへの同一アカウントの登録さえしなければ何ら問題はありません。
つまり、着信側がプッシュ型と常駐型に同一アカウントを登録してる場合で、呼び出し側がプッシュ型（プッシュ設定か標準または発信のみ設定でも結果は同じ）の場合に音声不通の問題がある、ということです。
着信側が同じ組み合わせでも発信側が常駐型の場合は音声不通問題は発生しません。
しかしながら前者の組み合わせで音声不通問題が発生したあとでは後者の方法でも音声不通問題が発生します。
neko さんという方から、SessionTalk から発信の場合、着信側２台が常駐型でも音声不通になる、とのご指摘をいただきました。
追試してみましたら確かに本事象が確認できました。
別の GS Wave から発信の場合は問題ないので、これは SessionTalk の問題ではないかと思われます。
My050 では試してはいないのですが同じ Acrobits 社の CloudSoftphone がベースですので同様の結果が予想されます。
いずれ試してみます。
発信側は My050（プッシュ設定）でも問題はなく着信側はプッシュ／非プッシュのいずれも通話可能です。
なぜにこのような事象になるのかはわかりませんが、プッシュサーバーがらみであることは間違いありません。
着信側が常駐型だけだと複数台に同一アカウントを設定してもまったく問題ありませんから。
SIP ログはともかく、RTP は Wireshark でも使わないとわかりません。
でも恐ろしい量の Wireshark ログになりますのでこれをキャプチャーしての解析は躊躇しています。
以上のこともあり、「イエデン（ブラステル２）」は HT701（ATA）の他にはワタシの iPhone 8 にのみ SessionTalk（Pro）に設定しています。
連れ合いの iPhone 6s には SessionTalk ではなく Acrobits に「ブラステル１」を設定しています。
つまり前記の ６つのケースのうちの【ケース ③】になります。
これにより、「ブラステル１」も「ブラステル２」も問題がでないようになりました。
実はブラステル番号はほかに３つ確保していますが、来年の今頃はなくなっているかも知れません（有料発信を止めていますので）。
それ以外にも SMARTalk の番号が２つ確保済みです。
※ 発信者 ID メソッドに関して
この項目は Acrobits でアカウントごとに設定できる項目ですが、ほかのソフトフォンアプリではこの種の設定項目はないと思います。
IP-PBX サーバーである Asterisk には設定できます。
以前に転送に関して P-Assert Identity 設定しないと転送先に発信元電番表示がされない問題がありましたが、同種のメソッドです。
「P-Preferred Identity（優先識別）」または「P-Assert Identity（強制識別）」は ID を電番で識別するか、ユーザー ID で識別するかの扱いと思われ、これに対応するかどうかはソフトフォン及び SIP サーバーの仕様に依存します。
どうやら、電番識別の際は問題がなさそうですが、プッシュサーバーと本来のブラステルの SIP サーバーとの関係性がよくはわかっていません。
ブラステルのサーバーは常駐型で REGISTER の場合の IP アドレスは登録したアプリ側の IP アドレス ですが、複数台にアカウントを登録時は 172.16.vvv.xxx というプライベートアドレスが割り当たります。
これはブラステルの Proxy サーバーによって割り当てられていると思われます。
このことにより、複数台の端末に登録可能な状態を作り出していると思われます（１台目から２台目、３台目〜 というように登録したときの SIP サーバーでのアドレスがそれぞれ異なるプライベートアドレスで、サーバー内ではこれによって一意に識別していると思われます）。
プッシュサーバーからの 代行 REGISTER もまた 172.16.yyy.zzz が割り当たっており、ここらあたりにこのような事象の発生要因が潜んでいるように思われます。
RTP パケットは、通常 End-to-End でやり取りするのですが、複数アカウント登録時はこのときのアドレス認識が失敗するケースがあると思われます。
このような見解はワタシの推測ですので、間違っているかも知れません。
しかしながら、コーデック問題ではないのは確かですので、RTP の宛先不明状態であるのはほぼ間違いないと思っています。
わかっていないのはなぜ、RTP 宛先不明状態が発生したりしなかったりするのか、という部分です。
ところがプッシュ型と非プッシュ型（常駐型）の両方に一つのアカウントを登録した場合、無音問題が発生し、通話不可となる場合があります（このためにブラステル社は非推奨にしていると思われます）。
常駐型同士の場合はこのような無音問題は発生しません。
プッシュ型を含む組み合わせでもすべてのケースで無音問題があるわけではなく、発生したりしなかったりと、不安定な状況なのです。
いったん無音問題が発生した場合、解消のためにはプッシュ型の方の登録を非プッシュにし直し、改めて登録オフ／オン（デアクティベート／アクティベート）することが必要です。
それでも解消しない場合はマイページからパスワード変更してサーバー側の状態をクリアにする必要があります。
どういう状況が NG でどういう条件なら OK になるかを改めて検証してみました。
なぜこのような検証をするかいいますと、iPhone は常駐型ではバッテリー消費が半端なく、プッシュ型が必須だからです。
Android は Doze 機構のおかげで常駐型でもバッテリー消費は抑えられています。
その代りディープスリープ時の不着信問題が発生する可能性があり、これはこれで悩ましいのですが。
プッシュ型として Acrobits / SessionTalk (Pro) を、常駐型として GS Wave を使い、同じアカウントをこれらプッシュ型と常駐型に登録して呼び出し通話確認しました。
そのときのお互いの振る舞いに奇妙なことがあり、整理の意味で状況を記載します。
使った番号は「ブラステル１」と「ブラステル２（イエデン）」です。
受信側のプッシュ型は「プッシュ着信設定」です。
これは「イエデン」を ATA 経由（常駐型と同等）で使える（発着信）と同時に、ワタシのスマホでも使える（発着信）ようにするのが目的です。
これができれば「イエデン」が外でも発着信可能となるのです。
「ブラステル１」は他からかける電話を想定し、発信されたときに「ブラステル２（イエデン）」側がどのようになるのか、という検証です。
「ブラステル１」ではなく携帯電話でもほかの SMARTalk などでもいいのですが、検証で有料通話にしないためにこのようにしました。
うまくいくケースでは携帯電話からの発信時と SMARTalk からの発信時も追加検証しています。
以下の ６つのケースを確認しました。
「受信（着信）」側のプッシュ型は iPhone 8 に設定、常駐型は Android 8 および iPhone 6s で検証しましたが、Android 8 と iPhone 6s で違いはありませんでした。
最終的には常駐型は HT701（ATA）でも検証しています。
【ケース ①】
発信：SessionTalk（ブラステル１）→ 受信：GS Wave （ブラステル２）
SessionTalk（ブラステル２）
このケースでは受信側はどちらも着信はしますが、
音声は送受ともに無音で通話不可です。
【ケース ②】
発信：SessionTalk（ブラステル１）→ 受信：GS Wave （ブラステル２）
Acrobits （ブラステル２）
このケースでは １項と結果は同じで通話不可です。
【ケース ③】
発信：Acrobits （ブラステル１）→ 受信：GS Wave （ブラステル２）
SessionTalk（ブラステル２）
このケースでは問題なくどちらも通話可能です。
【ケース ④】
発信：Acrobits （ブラステル１）→ 受信：GS Wave （ブラステル２）
Acrobits （ブラステル２）
このケースでは受信が Acrobits の方は通話可能ですが、GS Wave 側は着信時に
発信元選択行が２行現れ、どちらを選択するかで一方は通話可能で、他方は通話不可
です（「発信者 ID メソッド」の初期値が「ユーザー ID」であったため）。
さらに細かく発信側の「発信者ID メソッド（※）」を以下の設定にしたときの
GS Wave 側の状況は以下のとおりです。
P-Preferred Identity ： 通話可能
P-Assert Identity ： 通話可能
Remote-Party-ID ： 発信元選択行表示で一方は通話可能／他方は通話不可
From username ：（上と同じ）
選択行表示は「ユーザー ID」または「電番」で「ユーザー ID」の選択で通話可能
設定と動作の矛盾が感じられます
【ケース ⑤】
発信：GS Wave （ブラステル１）→ 受信：GS Wave （ブラステル２）
SessionTalk（ブラステル２）
このケースでは問題なくどちらも通話可能です。
【ケース ⑥】
発信：GS Wave （ブラステル１）→ 受信：GS Wave （ブラステル２）
Acrobits （ブラステル２）
このケースでは問題なくどちらも通話可能です。
以上の状況は受信側 GS Wave の部分を HT701（ATA）にしても同じ結果です。
【ケース ①】と【ケース ②】は着信側のアカウントを片方だけに設定の場合は通話も問題ありません。
プッシュ型が発信し、プッシュ型で着信の場合も複数デバイスへの同一アカウントの登録さえしなければ何ら問題はありません。
つまり、着信側がプッシュ型と常駐型に同一アカウントを登録してる場合で、呼び出し側がプッシュ型（プッシュ設定か標準または発信のみ設定でも結果は同じ）の場合に音声不通の問題がある、ということです。
着信側が同じ組み合わせでも発信側が常駐型の場合は音声不通問題は発生しません。
しかしながら前者の組み合わせで音声不通問題が発生したあとでは後者の方法でも音声不通問題が発生します。
neko さんという方から、SessionTalk から発信の場合、着信側２台が常駐型でも音声不通になる、とのご指摘をいただきました。
追試してみましたら確かに本事象が確認できました。
別の GS Wave から発信の場合は問題ないので、これは SessionTalk の問題ではないかと思われます。
発信側は My050（プッシュ設定）でも問題はなく着信側はプッシュ／非プッシュのいずれも通話可能です。
なぜにこのような事象になるのかはわかりませんが、プッシュサーバーがらみであることは間違いありません。
着信側が常駐型だけだと複数台に同一アカウントを設定してもまったく問題ありませんから。
SIP ログはともかく、RTP は Wireshark でも使わないとわかりません。
でも恐ろしい量の Wireshark ログになりますのでこれをキャプチャーしての解析は躊躇しています。
以上のこともあり、「イエデン（ブラステル２）」は HT701（ATA）の他にはワタシの iPhone 8 にのみ SessionTalk（Pro）に設定しています。
連れ合いの iPhone 6s には SessionTalk ではなく Acrobits に「ブラステル１」を設定しています。
つまり前記の ６つのケースのうちの【ケース ③】になります。
これにより、「ブラステル１」も「ブラステル２」も問題がでないようになりました。
実はブラステル番号はほかに３つ確保していますが、来年の今頃はなくなっているかも知れません（有料発信を止めていますので）。
それ以外にも SMARTalk の番号が２つ確保済みです。
※ 発信者 ID メソッドに関して
この項目は Acrobits でアカウントごとに設定できる項目ですが、ほかのソフトフォンアプリではこの種の設定項目はないと思います。
IP-PBX サーバーである Asterisk には設定できます。
以前に転送に関して P-Assert Identity 設定しないと転送先に発信元電番表示がされない問題がありましたが、同種のメソッドです。
「P-Preferred Identity（優先識別）」または「P-Assert Identity（強制識別）」は ID を電番で識別するか、ユーザー ID で識別するかの扱いと思われ、これに対応するかどうかはソフトフォン及び SIP サーバーの仕様に依存します。
どうやら、電番識別の際は問題がなさそうですが、プッシュサーバーと本来のブラステルの SIP サーバーとの関係性がよくはわかっていません。
ブラステルのサーバーは常駐型で REGISTER の場合の IP アドレスは登録したアプリ側の IP アドレス ですが、複数台にアカウントを登録時は 172.16.vvv.xxx というプライベートアドレスが割り当たります。
これはブラステルの Proxy サーバーによって割り当てられていると思われます。
このことにより、複数台の端末に登録可能な状態を作り出していると思われます（１台目から２台目、３台目〜 というように登録したときの SIP サーバーでのアドレスがそれぞれ異なるプライベートアドレスで、サーバー内ではこれによって一意に識別していると思われます）。
プッシュサーバーからの 代行 REGISTER もまた 172.16.yyy.zzz が割り当たっており、ここらあたりにこのような事象の発生要因が潜んでいるように思われます。
RTP パケットは、通常 End-to-End でやり取りするのですが、複数アカウント登録時はこのときのアドレス認識が失敗するケースがあると思われます。
このような見解はワタシの推測ですので、間違っているかも知れません。
しかしながら、コーデック問題ではないのは確かですので、RTP の宛先不明状態であるのはほぼ間違いないと思っています。
わかっていないのはなぜ、RTP 宛先不明状態が発生したりしなかったりするのか、という部分です。
2019-07-18
IP 電話の事業者間の接続
例えばブラステルと SMARTalk の間はどのようにお互いをつなぎ合っているのでしょうか。
ここでいう「つなぎ合う」は IP 電話での発着信をいいます。
上図の「当該事業者」が SMARTalk だとします。
右上の提携事業者が「東北インテリジェント通信株式会社（TOHKnet）」や「中部テレコミュニケーション株式会社（CTC）」などになります。
右下の「固定・携帯電話網」は NTT やドコモなどになります。
ブラステルは左下のような提携事業者がない、単独事業者になります。
通常、「提携先」とは無料通話になっていますが、これは IP 接続であるがゆえに殆どコストがかからないことから「無料通話サービス」していると思われます。
接続設定時の初期費用はかかりますが、運用コストは自社設備運用の中に含まれます。
そこで自社ユーザー同士と同じ扱いをしているわけです。
低コスト、といってもゼロではありません。
が、他事業者よりも少しでも優位に立つために提携先とは無料にして、そのことを「宣伝」しているわけです。
しかしながら、「固定・携帯電話網」とは接続料が発生し、かつ通話料も発生するので有料になっています。
「提携先」でない例えば SMARTalk からみたブラステルはこれにあたります。
直接に IP 接続していませんので、「固定・携帯電話網」経由で接続されていると思われます。
NTT はすべての電話網を接続管理していますので、IP 電話事業者からすると、NTT 経由で他の IP 電話事業者や固定電話・携帯電話と接続するほうが接続先管理の必要がなくなり、設備も楽になります。
ちなみに IP 電話の場合は呼制御（発着信など）を SIP プロトコルで行い、音声はコーデックを処理して RTP パケットで流し合います。
固定電話や携帯電話とは NTT やドコモなどの IP 電話と既設交換機間の変換を通じて呼制御や音声送受信を行います。
ここでいう「つなぎ合う」は IP 電話での発着信をいいます。
上図の「当該事業者」が SMARTalk だとします。
右上の提携事業者が「東北インテリジェント通信株式会社（TOHKnet）」や「中部テレコミュニケーション株式会社（CTC）」などになります。
右下の「固定・携帯電話網」は NTT やドコモなどになります。
ブラステルは左下のような提携事業者がない、単独事業者になります。
通常、「提携先」とは無料通話になっていますが、これは IP 接続であるがゆえに殆どコストがかからないことから「無料通話サービス」していると思われます。
接続設定時の初期費用はかかりますが、運用コストは自社設備運用の中に含まれます。
そこで自社ユーザー同士と同じ扱いをしているわけです。
低コスト、といってもゼロではありません。
が、他事業者よりも少しでも優位に立つために提携先とは無料にして、そのことを「宣伝」しているわけです。
しかしながら、「固定・携帯電話網」とは接続料が発生し、かつ通話料も発生するので有料になっています。
「提携先」でない例えば SMARTalk からみたブラステルはこれにあたります。
直接に IP 接続していませんので、「固定・携帯電話網」経由で接続されていると思われます。
NTT はすべての電話網を接続管理していますので、IP 電話事業者からすると、NTT 経由で他の IP 電話事業者や固定電話・携帯電話と接続するほうが接続先管理の必要がなくなり、設備も楽になります。
ちなみに IP 電話の場合は呼制御（発着信など）を SIP プロトコルで行い、音声はコーデックを処理して RTP パケットで流し合います。
固定電話や携帯電話とは NTT やドコモなどの IP 電話と既設交換機間の変換を通じて呼制御や音声送受信を行います。
2019-07-16
Celtic Woman
「ケルトの女性」というアイルランドのボーカルグループです。
最初のアルバムのタイトルが Celtic Woman で、このときは彼女たちのことは Celtic Ladies と呼んでいましたが、グループ名はハッキリしていなかったようです。
以降は Celtic Woman をグループ名にしたようです。
なぜなのかグループ名が Celtic Women（ケルトの女性たち）と複数形ではないのです（デビュー・アルバム時は "Ladies" だったのにです）。
ファースト・アルバムは 2005年から2006年にかけてビルボードランキング1位を連続８１週という快挙を成し遂げたグループです。
当初は一人ひとりが違う曲を順繰りに歌う、ということが多く、全員揃って歌う、という感じではなく、それぞれの個性を大事にするという感じでした。
ですのでフィドラー（バイオリン奏者の） Máiréad Nesbitt もソロ演奏ででています。
は、ファースト・アルバムに収録された曲で彼女たちの原点の曲でもあるのですが、荒川静香さんがトリノオリンピックで金メダル獲得時のエキシビジョンで演じたときに使われ、荒川静香さんご自身も大変お気に入りだそうです。
で、Officail Video は下記です。
https://www.youtube.com/watch?v=Yfwlj0gba_k&list=PLRAb2unuFFd3HtV6BKPBNz0-Bsn8AYD_w&index=1
冒頭に３人が映っていますが、左から Lisa Kelly / Máiréad Nesbitt / Chloë Agnew です。
もともとは Secret Garden というピアノとフィドル（バイオリン）の男女ペアの演奏曲だったのですが、Celtic Woman がカバーして大変にヒットし、有名になった曲です。
下記はオリジナルバージョンでフィドル（バイオリン）が Fionnuala Sherry、ピアノがこの曲を作曲した Rolf Rovland とのペアの Secret Garden と Tracey Campbell（女性歌手）と Espen Grjotheim（男性歌手）のコラボレーションです。
ちなみに作詞は Brendan Graham です。
https://www.youtube.com/watch?v=sHpwbh9lxxY
多くの歌手が Secret Garden の曲をカバーしていますが、Celtic Woman もその中の一つです。
Celtic Woman はほかにも Secret Garden の曲をカバーしています。
Celtic Woman はメンバーが４人〜６人で変遷してきていますが、ファースト・アルバムの当初メンバーは
Lisa Kelly
Chloë Agnew
Órlagh Fallon（歌＆ハープ奏者）
Méav Ní Mhaolchatha
Máiréad Nesbitt（フィドル奏者）
です。
Official Video のメンバーはこの当初メンバーではなく、
左から順に以下の人たちです。
Alex Sharpe
Lisa Kelly
Máiréad Nesbitt
Chloë Agnew
Lynn Hilary
つまり、Órlagh Fallon 、Méav Ní Mhaolchatha の代わりに Alex Sharpe と Lynn Hilary が入っています。
Celtic Woman はどんな曲でも本当に楽しそうに歌っていて、大変に癒やされます。
マレード・ネズビットは歌わずにフィドル（バイオリン）を演奏しているのですが、舞台を飛び跳ねる妖精みたいだ、という評価があるようです。
リサ・ケリーはリーダー的存在でしたが、いまは脱退しています。
オーラ・ファロンもまた脱退しました。
アレックス・シャープとリン・ヒラリーはともに家族との時間を大事にしたいと、2010 年にそれぞれ脱退、以後一時的に再加入したこともあったようですが、いまは引退のようです。
残る当初メンバーも現在は脱退し、ソロ活動したり、引退したりです。
メイブ・ニー・ウェルカハは出産を期に脱退し、時折コンサートなど参加していたようですが現在はわかりません。
クローエ・アグニューはファースト・アルバム当初はまだ１６歳、ブサカワぽっちゃりでしたが、３０歳になりスマートな美しい女性に変貌しました。
http://www.chloeagnewofficial.com/press
Officail Video と上の彼女のホームページを比べてみてください。
Official Video はたしか ２０歳、ホームページは３０歳の現在です。
下記は１０代の頃の若かりし姿です。
大人になった姿とはかなり印象が違いますね。
https://www.youtube.com/watch?v=oTOpx3iulaI&list=PL8B1A988114452E4F&index=9
現在のメンバーは当初メンバーの誰も残っていなくて全員入れ替わっています。
クローエ・アグニューが若かった頃からいたせいか、一番長くメンバーにいましたが、いまはソロ活動しています。
Hayley Westenra もサード・アルバム当時にメンバーだったことがあります。
https://www.youtube.com/watch?v=faKFcfytlxU
は当初メンバーに加えて Hayley Westenra が入っている You Raise Me Up です。
Hayley Westenra もそうですが、Sarah Brightman / Katherine Jenkins / Céline Dion / Sarah Alainn など、声量豊かで、美人で、高音域の伸びのある歌手たちと同様、Celtic Woman のメンバーもまた、声量豊か、美人、高音域が伸びやかな人たちです。
珍しいところではこの曲を自衛官・鶫真衣（つぐみ・まい）さんが披露された動画が Youtube にあります。
この方も素晴らしい。
The Prayer / Time to say Good-bye / My heart will go on などが歌える方々は優れた歌姫です。
これらの曲はここに紹介した方々が歌っていますので、ぜひ一度聴いて見てください。
Hayley Westenra が１３歳のときにニュージーランドの TV 番組「６０分」でレポートされたときの珍しいビデオです。
https://www.youtube.com/watch?v=FTYWh0QN9fs
Chloë Agnew も１６歳でデビューしたようですし、十代のこの頃にすでに素晴らしい声で歌を披露してくれています。
Chloë Agnew は現在３０歳、Hayley Westenraは３１歳になったはずです。
ともに美しい大人の女性になりました。
最初のアルバムのタイトルが Celtic Woman で、このときは彼女たちのことは Celtic Ladies と呼んでいましたが、グループ名はハッキリしていなかったようです。
以降は Celtic Woman をグループ名にしたようです。
なぜなのかグループ名が Celtic Women（ケルトの女性たち）と複数形ではないのです（デビュー・アルバム時は "Ladies" だったのにです）。
ファースト・アルバムは 2005年から2006年にかけてビルボードランキング1位を連続８１週という快挙を成し遂げたグループです。
当初は一人ひとりが違う曲を順繰りに歌う、ということが多く、全員揃って歌う、という感じではなく、それぞれの個性を大事にするという感じでした。
ですのでフィドラー（バイオリン奏者の） Máiréad Nesbitt もソロ演奏ででています。
You Raise Me Up
は、ファースト・アルバムに収録された曲で彼女たちの原点の曲でもあるのですが、荒川静香さんがトリノオリンピックで金メダル獲得時のエキシビジョンで演じたときに使われ、荒川静香さんご自身も大変お気に入りだそうです。
で、Officail Video は下記です。
https://www.youtube.com/watch?v=Yfwlj0gba_k&list=PLRAb2unuFFd3HtV6BKPBNz0-Bsn8AYD_w&index=1
冒頭に３人が映っていますが、左から Lisa Kelly / Máiréad Nesbitt / Chloë Agnew です。
もともとは Secret Garden というピアノとフィドル（バイオリン）の男女ペアの演奏曲だったのですが、Celtic Woman がカバーして大変にヒットし、有名になった曲です。
下記はオリジナルバージョンでフィドル（バイオリン）が Fionnuala Sherry、ピアノがこの曲を作曲した Rolf Rovland とのペアの Secret Garden と Tracey Campbell（女性歌手）と Espen Grjotheim（男性歌手）のコラボレーションです。
ちなみに作詞は Brendan Graham です。
https://www.youtube.com/watch?v=sHpwbh9lxxY
多くの歌手が Secret Garden の曲をカバーしていますが、Celtic Woman もその中の一つです。
Celtic Woman はほかにも Secret Garden の曲をカバーしています。
Celtic Woman はメンバーが４人〜６人で変遷してきていますが、ファースト・アルバムの当初メンバーは
Lisa Kelly
Chloë Agnew
Órlagh Fallon（歌＆ハープ奏者）
Méav Ní Mhaolchatha
Máiréad Nesbitt（フィドル奏者）
です。
Official Video のメンバーはこの当初メンバーではなく、
左から順に以下の人たちです。
Alex Sharpe
Lisa Kelly
Máiréad Nesbitt
Chloë Agnew
Lynn Hilary
つまり、Órlagh Fallon 、Méav Ní Mhaolchatha の代わりに Alex Sharpe と Lynn Hilary が入っています。
Celtic Woman はどんな曲でも本当に楽しそうに歌っていて、大変に癒やされます。
マレード・ネズビットは歌わずにフィドル（バイオリン）を演奏しているのですが、舞台を飛び跳ねる妖精みたいだ、という評価があるようです。
リサ・ケリーはリーダー的存在でしたが、いまは脱退しています。
オーラ・ファロンもまた脱退しました。
アレックス・シャープとリン・ヒラリーはともに家族との時間を大事にしたいと、2010 年にそれぞれ脱退、以後一時的に再加入したこともあったようですが、いまは引退のようです。
残る当初メンバーも現在は脱退し、ソロ活動したり、引退したりです。
メイブ・ニー・ウェルカハは出産を期に脱退し、時折コンサートなど参加していたようですが現在はわかりません。
クローエ・アグニューはファースト・アルバム当初はまだ１６歳、ブサカワぽっちゃりでしたが、３０歳になりスマートな美しい女性に変貌しました。
http://www.chloeagnewofficial.com/press
Officail Video と上の彼女のホームページを比べてみてください。
Official Video はたしか ２０歳、ホームページは３０歳の現在です。
下記は１０代の頃の若かりし姿です。
大人になった姿とはかなり印象が違いますね。
https://www.youtube.com/watch?v=oTOpx3iulaI&list=PL8B1A988114452E4F&index=9
現在のメンバーは当初メンバーの誰も残っていなくて全員入れ替わっています。
クローエ・アグニューが若かった頃からいたせいか、一番長くメンバーにいましたが、いまはソロ活動しています。
Hayley Westenra もサード・アルバム当時にメンバーだったことがあります。
https://www.youtube.com/watch?v=faKFcfytlxU
は当初メンバーに加えて Hayley Westenra が入っている You Raise Me Up です。
Hayley Westenra もそうですが、Sarah Brightman / Katherine Jenkins / Céline Dion / Sarah Alainn など、声量豊かで、美人で、高音域の伸びのある歌手たちと同様、Celtic Woman のメンバーもまた、声量豊か、美人、高音域が伸びやかな人たちです。
珍しいところではこの曲を自衛官・鶫真衣（つぐみ・まい）さんが披露された動画が Youtube にあります。
この方も素晴らしい。
The Prayer / Time to say Good-bye / My heart will go on などが歌える方々は優れた歌姫です。
これらの曲はここに紹介した方々が歌っていますので、ぜひ一度聴いて見てください。
Hayley Westenra が１３歳のときにニュージーランドの TV 番組「６０分」でレポートされたときの珍しいビデオです。
https://www.youtube.com/watch?v=FTYWh0QN9fs
Chloë Agnew も１６歳でデビューしたようですし、十代のこの頃にすでに素晴らしい声で歌を披露してくれています。
Chloë Agnew は現在３０歳、Hayley Westenraは３１歳になったはずです。
ともに美しい大人の女性になりました。
2019-07-06
常駐型とプッシュ型のソフトフォン
常駐型には GS Wave や Zoiper (Push op. なし) などがあり、プッシュ型には SessionTalk や Acrobits, CloudSoftphone (My050 / SMARTalk) などがあります。
下図は簡略的に表現した図で、本来の SIP（Session Initiate Protocol）シーケンスはもう少し複雑です。
左のクライアントが常駐型で右がプッシュ型の場合です。
常駐型は直接、目的の SIP Proxy に REGISTER します。
REGISTER というのはロケーションサーバーに位置（IP アドレス）情報を登録することです。
この「位置登録」というのはレガシーな交換網の場合も同様のことを行っています。
IP アドレスの代わりに「ポイントコード」というアドレス体系で末端の電話機が収容されている交換機を管理していて、STP という信号線管理サーバーを通じてトランクを張る（回線をつなぐ）ようになっていますが、SIP も基本的には似ています。
位置登録のときに、SIP Proxy は配下のデータベースに問い合わせて認証処理を行うとともに課金準備をします。
一方、プッシュ型は Push Server（代行 SIP Proxy）がクライアントの REGISTER を受けて目的とする SIP Proxy に REGISTER 代行します。
Push Server はプッシュ型ソフトフォンベンダー（Sessiontalk Ltd. や Acrobits, s.r.o. など）、または ITSP（IP 電話事業者）が用意します。
Cloud ソフトフォンの場合で（SessionTalk Cloud や Cloud Softphoneなど）、ITSP がカスタマイズの一環で Push Server を用意するか、そうでない場合はソフトフォンベンダーのものが使われます。
Acrobits / SessionTalk (Pro) Softphone の場合はソフトフォンベンダーが用意したものです。
My050 / SMARTalk がどちらなのかは調べていないので不明ですが、ここでの記事は仕組みを記載していますので、どちらの Push Server でも仕組みは同じです。
本来の SIP Proxy は、この「代行 SIP Proxy」の位置登録を行い、「代行 SIP Proxy」はプッシュ型クライアントの位置登録をします。
左のクライアントから右のクライアントに発呼（INVITE）すると ③ ④ ⑤ と INVITE されて最終的に同一コーデックならば直接クライアント同士が通話ストリームのやり取りを行います。
コーデックが異なる場合は SIP Proxy がコーデックを変換します（しない場合は無音になります）。
通常、プッシュ型 SIP app はフォアグラウンドにあるときは本来の SIP Proxy にREGISTER し、バックグラウンドに落ちたタイミングで「代行 SIP Proxy」に REGISTER し直すようです。
「代行 SIP Proxy」は iPhone（または Android）のプッシュ機構を通じて端末にプッシュ信号を送り、これを受け取った端末は SIP app を起動し、INVITE を送り込みます。
いわゆる着信動作に入るわけです。
着信側が常駐型の場合は、バックグラウンドで動作中ですから、INVITE を受け取ります。
このときに何らかの原因でバックグラウンドで動作状態にないときは着信が失敗します。
REGISTER は一定間隔で行い続けますがこれが途切れた場合も着信が失敗します。
※ Push Server は SessionTalk の場合、以下の各都市に設置されており、
アプリでどこの Push Server を使うかを設定できるようになっています。
ヨハネスブルグ（南ア）、ロンドン（英）、ロンドン２（英）、
オレゴン（米・西部）、バージニア（米・東部）、サンパウロ（伯）、
バンガロア（印）、シンガポール、東京（日）、シドニー（豪）、
auto（おまかせ）
どこのサーバーを使うかによっては呼び出し時の多少の遅延はあっても
通話は通常端末同士のやり取りですので、サーバーの設置場所の影響は
ありません。
ですので Tokyo(Japan) / auto のいずれかでいいでしょう。
PUSH 通知は Android と iOS は概念的には同じです。
iOS のプッシュ機構には iOS ８ から VoIP PUSH が備わりました（下表）。
Push ｎotification は WiFi <---> 4G (LTE) で IP アドレスが変わったりした場合は、常にプッシュ通知を受け取れるようにしています。
そして、「プッシュ通知」を受けたあと、アプリを起こしアプリは改めて最新の位置登録をするために REGISTER します。
そこに Push Server が INVITE を投げます。
ですので、アプリが未起動・消去（強制消去を含む）されていても、またその間に IP アドレスが変わっても正しく INVITE に応答できるわけです。
したがって、プッシュサーバーがどこに設置かで多少の遅延があっても、それは電話の呼び出しに対して０〜１秒程度の遅延でしかありませんし、音声は直に端末同士でやりとりなのでプッシュサーバーの設置位置の影響を受けないということです。
下図は簡略的に表現した図で、本来の SIP（Session Initiate Protocol）シーケンスはもう少し複雑です。
左のクライアントが常駐型で右がプッシュ型の場合です。
常駐型は直接、目的の SIP Proxy に REGISTER します。
REGISTER というのはロケーションサーバーに位置（IP アドレス）情報を登録することです。
この「位置登録」というのはレガシーな交換網の場合も同様のことを行っています。
IP アドレスの代わりに「ポイントコード」というアドレス体系で末端の電話機が収容されている交換機を管理していて、STP という信号線管理サーバーを通じてトランクを張る（回線をつなぐ）ようになっていますが、SIP も基本的には似ています。
位置登録のときに、SIP Proxy は配下のデータベースに問い合わせて認証処理を行うとともに課金準備をします。
一方、プッシュ型は Push Server（代行 SIP Proxy）がクライアントの REGISTER を受けて目的とする SIP Proxy に REGISTER 代行します。
Push Server はプッシュ型ソフトフォンベンダー（Sessiontalk Ltd. や Acrobits, s.r.o. など）、または ITSP（IP 電話事業者）が用意します。
Cloud ソフトフォンの場合で（SessionTalk Cloud や Cloud Softphoneなど）、ITSP がカスタマイズの一環で Push Server を用意するか、そうでない場合はソフトフォンベンダーのものが使われます。
Acrobits / SessionTalk (Pro) Softphone の場合はソフトフォンベンダーが用意したものです。
My050 / SMARTalk がどちらなのかは調べていないので不明ですが、ここでの記事は仕組みを記載していますので、どちらの Push Server でも仕組みは同じです。
本来の SIP Proxy は、この「代行 SIP Proxy」の位置登録を行い、「代行 SIP Proxy」はプッシュ型クライアントの位置登録をします。
左のクライアントから右のクライアントに発呼（INVITE）すると ③ ④ ⑤ と INVITE されて最終的に同一コーデックならば直接クライアント同士が通話ストリームのやり取りを行います。
コーデックが異なる場合は SIP Proxy がコーデックを変換します（しない場合は無音になります）。
通常、プッシュ型 SIP app はフォアグラウンドにあるときは本来の SIP Proxy にREGISTER し、バックグラウンドに落ちたタイミングで「代行 SIP Proxy」に REGISTER し直すようです。
「代行 SIP Proxy」は iPhone（または Android）のプッシュ機構を通じて端末にプッシュ信号を送り、これを受け取った端末は SIP app を起動し、INVITE を送り込みます。
いわゆる着信動作に入るわけです。
着信側が常駐型の場合は、バックグラウンドで動作中ですから、INVITE を受け取ります。
このときに何らかの原因でバックグラウンドで動作状態にないときは着信が失敗します。
REGISTER は一定間隔で行い続けますがこれが途切れた場合も着信が失敗します。
※ Push Server は SessionTalk の場合、以下の各都市に設置されており、
アプリでどこの Push Server を使うかを設定できるようになっています。
ヨハネスブルグ（南ア）、ロンドン（英）、ロンドン２（英）、
オレゴン（米・西部）、バージニア（米・東部）、サンパウロ（伯）、
バンガロア（印）、シンガポール、東京（日）、シドニー（豪）、
auto（おまかせ）
どこのサーバーを使うかによっては呼び出し時の多少の遅延はあっても
通話は通常端末同士のやり取りですので、サーバーの設置場所の影響は
ありません。
ですので Tokyo(Japan) / auto のいずれかでいいでしょう。
PUSH 通知は Android と iOS は概念的には同じです。
iOS のプッシュ機構には iOS ８ から VoIP PUSH が備わりました（下表）。
- アプリは Apple Push Notification Service（APNS）/ Google FCM にデバイストークンを要求します。
- アプリは、プッシュ通知を送信するアドレスとして機能するトークンを受け取ります。
- アプリは SIP REGISTER メッセージで Push Server (SIP Proxy) に登録します。 デバイストークンおよびその他の必要な情報をこのヘッダーに含めて、 REGISTERメッセージに「Push Server」ヘッダーを追加し、Push Server にこの拡張機能のプッシュ通知を受信したいことを知らせる必要があります。
- ユーザーがアプリケーションを強制終了します。
- 誰かが電話をかけたとき、そのアカウントの登録が期限切れになっていない場合、Push Server は「適切な連絡先アドレス」に INVITE メッセージを送信し、APNS / FCM にデバイストークンとともに「プッシュ通知」を送信します。
- アプリは終了しているので、 INVITE メッセージはアプリによって受信されません。
- APNS / FCM はデバイスに「プッシュ通知」を送信します。
- iOS / Android デバイスはそのプッシュ通知を受信し、モバイルデバイスに着信があることを警告します。
- アプリが起動され、Push Server に自動的に REGISTER (登録) されます。
- REGISTER (登録)が成功すると、push Server は新しい登録から取得した INVITEメッセージを連絡先アドレスに送信します。
- これで、アプリは INVITE メッセージを受信して電話に応答します。
Push ｎotification は WiFi <---> 4G (LTE) で IP アドレスが変わったりした場合は、常にプッシュ通知を受け取れるようにしています。
そして、「プッシュ通知」を受けたあと、アプリを起こしアプリは改めて最新の位置登録をするために REGISTER します。
そこに Push Server が INVITE を投げます。
ですので、アプリが未起動・消去（強制消去を含む）されていても、またその間に IP アドレスが変わっても正しく INVITE に応答できるわけです。
したがって、プッシュサーバーがどこに設置かで多少の遅延があっても、それは電話の呼び出しに対して０〜１秒程度の遅延でしかありませんし、音声は直に端末同士でやりとりなのでプッシュサーバーの設置位置の影響を受けないということです。