ページ

2019-07-19

プッシュ型と常駐型への同一アカウント登録での奇妙な振る舞い

ブラステルは一つのアカウントを複数台の端末に登録できます(ブラステル社はできることを認めているが非推奨です)。


ところがプッシュ型と非プッシュ型(常駐型)の両方に一つのアカウントを登録した場合、無音問題が発生し、通話不可となる場合があります(このためにブラステル社は非推奨にしていると思われます)。



常駐型同士の場合はこのような無音問題は発生しません。



プッシュ型を含む組み合わせでもすべてのケースで無音問題があるわけではなく、発生したりしなかったりと、不安定な状況なのです。


いったん無音問題が発生した場合、解消のためにはプッシュ型の方の登録を非プッシュにし直し、改めて登録オフ/オン(デアクティベート/アクティベート)することが必要です。

それでも解消しない場合はマイページからパスワード変更してサーバー側の状態をクリアにする必要があります。




どういう状況が NG でどういう条件なら OK になるかを改めて検証してみました。

なぜこのような検証をするかいいますと、iPhone は常駐型ではバッテリー消費が半端なく、プッシュ型が必須だからです。



Android は Doze 機構のおかげで常駐型でもバッテリー消費は抑えられています。

その代りディープスリープ時の不着信問題が発生する可能性があり、これはこれで悩ましいのですが。




プッシュ型として Acrobits / SessionTalk (Pro) を、常駐型として GS Wave を使い、同じアカウントをこれらプッシュ型と常駐型に登録して呼び出し通話確認しました。




そのときのお互いの振る舞いに奇妙なことがあり、整理の意味で状況を記載します。


使った番号は「ブラステル1」と「ブラステル2(イエデン)」です。
受信側のプッシュ型は「プッシュ着信設定」です。


これは「イエデン」を ATA 経由(常駐型と同等)で使える(発着信)と同時に、ワタシのスマホでも使える(発着信)ようにするのが目的です。


これができれば「イエデン」が外でも発着信可能となるのです。


「ブラステル1」は他からかける電話を想定し、発信されたときに「ブラステル2(イエデン)」側がどのようになるのか、という検証です。

「ブラステル1」ではなく携帯電話でもほかの SMARTalk などでもいいのですが、検証で有料通話にしないためにこのようにしました。


うまくいくケースでは携帯電話からの発信時と SMARTalk からの発信時も追加検証しています。




以下の 6つのケースを確認しました。


「受信(着信)」側のプッシュ型は iPhone 8 に設定、常駐型は Android 8 および iPhone 6s で検証しましたが、Android 8 と iPhone 6s で違いはありませんでした。


最終的には常駐型は HT701(ATA)でも検証しています。


ケース ①

 発信:SessionTalk(ブラステル1)→ 受信:GS Wave  (ブラステル2)
                      SessionTalk(ブラステル2)

 このケースでは受信側はどちらも着信はしますが、
 音声は送受ともに無音で通話不可です。


ケース ②

 発信:SessionTalk(ブラステル1)→ 受信:GS Wave  (ブラステル2)
                      Acrobits   (ブラステル2)

 このケースでは 1項と結果は同じで通話不可です。


ケース ③

 発信:Acrobits  (ブラステル1)→ 受信:GS Wave  (ブラステル2)
                      SessionTalk(ブラステル2)

 このケースでは問題なくどちらも通話可能です。


ケース ④

 発信:Acrobits  (ブラステル1)→ 受信:GS Wave  (ブラステル2)
                      Acrobits  (ブラステル2)

 このケースでは受信が Acrobits の方は通話可能ですが、GS Wave 側は着信時に
 発信元選択行が2行現れ、どちらを選択するかで一方は通話可能で、他方は通話不可
 です(「発信者 ID メソッド」の初期値が「ユーザー ID」であったため)。

 さらに細かく発信側の「発信者ID メソッド()」を以下の設定にしたときの
 GS Wave 側の状況は以下のとおりです。

  P-Preferred Identity : 通話可能
  P-Assert Identity  : 通話可能
  Remote-Party-ID  : 発信元選択行表示で一方は通話可能他方は通話不可
  From username    :(上と同じ)

  選択行表示は「ユーザー ID」または「電番」で「ユーザー ID」の選択で通話可能
  設定と動作の矛盾が感じられます



ケース ⑤

 発信:GS Wave (ブラステル1)→ 受信:GS Wave  (ブラステル2)
                      SessionTalk(ブラステル2)

 このケースでは問題なくどちらも通話可能です。


ケース ⑥

 発信:GS Wave (ブラステル1)→ 受信:GS Wave  (ブラステル2)
                      Acrobits  (ブラステル2)

 このケースでは問題なくどちらも通話可能です。


 

 以上の状況は受信側 GS Wave の部分を HT701(ATA)にしても同じ結果です。



ケース ①】と【ケース ②】は着信側のアカウントを片方だけに設定の場合は通話も問題ありません。

プッシュ型が発信し、プッシュ型で着信の場合も複数デバイスへの同一アカウントの登録さえしなければ何ら問題はありません。





つまり、着信側がプッシュ型と常駐型に同一アカウントを登録してる場合で、呼び出し側がプッシュ型(プッシュ設定か標準または発信のみ設定でも結果は同じ)の場合に音声不通の問題がある、ということです。


着信側が同じ組み合わせでも発信側が常駐型の場合は音声不通問題は発生しません



しかしながら前者の組み合わせで音声不通問題が発生したあとでは後者の方法でも音声不通問題が発生します。



neko さんという方から、SessionTalk から発信の場合、着信側2台が常駐型でも音声不通になる、とのご指摘をいただきました。

追試してみましたら確かに本事象が確認できました。

別の GS Wave から発信の場合は問題ないので、これは SessionTalk の問題ではないかと思われます。



My050 では試してはいないのですが同じ Acrobits 社の CloudSoftphone がベースですので同様の結果が予想されます。


いずれ試してみます。
発信側は My050(プッシュ設定)でも問題はなく着信側はプッシュ/非プッシュのいずれも通話可能です。



なぜにこのような事象になるのかはわかりませんが、プッシュサーバーがらみであることは間違いありません。


着信側が常駐型だけだと複数台に同一アカウントを設定してもまったく問題ありませんから。


SIP ログはともかく、RTP は Wireshark でも使わないとわかりません。

でも恐ろしい量の Wireshark ログになりますのでこれをキャプチャーしての解析は躊躇しています。




以上のこともあり、「イエデン(ブラステル2)」は HT701(ATA)の他にはワタシの iPhone 8 にのみ SessionTalk(Pro)に設定しています。


連れ合いの iPhone 6s には SessionTalk ではなく Acrobits に「ブラステル1」を設定しています。


つまり前記の 6つのケースのうちの【ケース ③】になります。

これにより、「ブラステル1」も「ブラステル2」も問題がでないようになりました。


実はブラステル番号はほかに3つ確保していますが、来年の今頃はなくなっているかも知れません(有料発信を止めていますので)。


それ以外にも SMARTalk の番号が2つ確保済みです。






※ 発信者 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 サーバーによって割り当てられていると思われます。

このことにより、複数台の端末に登録可能な状態を作り出していると思われます(1台目から2台目、3台目〜 というように登録したときの SIP サーバーでのアドレスがそれぞれ異なるプライベートアドレスで、サーバー内ではこれによって一意に識別していると思われます)。


プッシュサーバーからの 代行 REGISTER もまた 172.16.yyy.zzz が割り当たっており、ここらあたりにこのような事象の発生要因が潜んでいるように思われます。


RTP パケットは、通常 End-to-End でやり取りするのですが、複数アカウント登録時はこのときのアドレス認識が失敗するケースがあると思われます。




このような見解はワタシの推測ですので、間違っているかも知れません。



しかしながら、コーデック問題ではないのは確かですので、RTP の宛先不明状態であるのはほぼ間違いないと思っています。


わかっていないのはなぜ、RTP 宛先不明状態が発生したりしなかったりするのか、という部分です。









8 件のコメント:

  1. バイク野郎様

    大変の詳しいようですので、質問させてください。

    私は、HT701 と HT802 に同一のブラステルアカウントを設定し、
    電話機をHT802に接続し、HT701はルーターに接続したまま放置していましたら、
    HT802から発信できなくなってしまいました。
    全て発信できないわけでなく、有料発信ができないのです。0120− や、050−6868−0000(ブラステル社のテスト番号)は問題なくかかります。

    その後、HT701が壊れてしまいまして、HT802で着信のみ可、で使っていますが、
    今年の12月までに課金しないと、アカウントが消されることとなります。
    要するに、今は、年額500円で着信のみの「家電」として使っている状態です。

    ブラステルのパスワードを変えても、
    以下のような設定をしても、
    HT802を一度リセットしても状況は変わりません。
    「my050」&スマフォでは、怖いのでやってません。

    どうすれば治るでしょうか?
    誠にすみません、質問させていただきました。
    よろしくお願いします。

    ----------
    ・ADVANCED SETTINGS→STUN serverにstun.l.google.com:19302を追加
    ・FXS PORT2→NAT Traversal をSTUNに
    ・FXS PORT2→Use Random SIP Port、Use Random RTP PortをYesに
    ----------

    返信削除
  2. taropii さん、こんばんは。

    まず、発信できないときの状況をもう少し詳しくお願いします。
    発信先は固定電話でしょうか。携帯電話でしょうか。IP電話でしょうか。
    チャージ金額はいくら残っているのでしょうか。

    「〇〇分ご利用できます。〜〜」というメッセージは流れるのでしょうか。
    どういう状態で発信できないのかを教えて下さい。

    STUN サーバー設定はする必要性があるのでしょうか。
    NAT Traversal でNATを越えられないようなネットの設定でしょうか。

    外向きのポートの制限はしていないですよね。
    その場合は Random port はよくないと思われます。

    スマホでは怖いとおっしゃる意味がよくわからないのですが。

    スマホでも試してみてできないのでしょうか。

    情報が少なく判断しにくいのですが。

    返信削除
  3. バイク野郎 様

    ご返信ありがとうございます。
    以下にご質問に従いお返事します。

    > 発信先は固定電話でしょうか。携帯電話でしょうか。IP電話でしょうか。
    > チャージ金額はいくら残っているのでしょうか。
    発信先は、上記全てです。つまり、課金が発生する電話番号は全てNGです。
    チャージ額は900円ほどあります。
    逆に課金が発生しない番号はOKです。

    > 「〇〇分ご利用できます。〜〜」というメッセージは流れるのでしょうか。
    > どういう状態で発信できないのかを教えて下さい。
    上記メッセージは流れません。直ぐに「プープープー」という音声になります。
    課金が発生しない、繋がる電話番号は、上記「〇〇分ご利用できます。〜〜」は流れず、直ぐにつながります。
    ブラステルの課金関係のサーバーが今回の問題に関係していると思います。

    > STUN サーバー設定はする必要性があるのでしょうか。
    > NAT Traversal でNATを越えられないようなネットの設定でしょうか。
    全く必要ないと思います。以下でそのような情報があったので、やってみただけです。
    https://www.neko01.com/pc/keitai/?page_id=9#HT702

    > 外向きのポートの制限はしていないですよね。
    > その場合は Random port はよくないと思われます。
    内向きのポート制限しかやっていません。

    > スマホでは怖いとおっしゃる意味がよくわからないのですが。
    > スマホでも試してみてできないのでしょうか。

    今の「家電」の電話番号は「いろんな業者」「地域一帯」「友人関係など」に公開している電話番号でして、「my050」に設定した後、「家電」で使えなくなる可能性に怖さを感じています。
    バイク野郎さんにスマフォで一度やってみることを進められればやってみます。
    ブラステルのサイトには、my050以外はサポートしない、と明確に書いてあります。
    my050に設定すると確実に「発信・着信」可能となると思いますが、今できているHT802の着信ができなくなる可能性を危惧しています。

    taropii

    返信削除
  4. 「ブー ブー ブー」というのはつながっていない状態のときの音ですね。
    050-6968-0000 にはかかるということなので、なぜなのかがよくわかりません。

    スマホの設定はプッシュ設定するとイエデンとバッティングしますがプッシュ設定しなければ大丈夫です。
    (プッシュ設定をやめて「発信で使用」に設定します)

    なお、万一着信しなくなった場合はブラステルのマイページにログインしてパスワードを変更すれば登録が初期化されますから、そのパスワードでHT802側を再設定すれば問題は発生しません。

    スマホではうまくいくようでしたらHT802の設定のどこかが誤っていると思われます。

    下記サイトに HT701 の設定情報を記載しています。

    https://bike8615.blogspot.com/2017/07/grandstream-ht701.html

    参考にしてみてください。
    この中の後ろの方にご質問をいただいてやり取りした内容もありますので、
    その部分も参考にしてみてください。

    返信削除
  5. バイク野郎さん

    大変ご迷惑をおかけしました。
    結論を申し上げますと、ご指示どおり「My050」をインストールし、Wifiで問題なく通話できることを確認した後、設定用ブログを拝見し、もしかすると、と思い、
    ブラステルのパスワードを入れて、Update -> Apply -> Reboot

    私は、「UPDATE」をやってなかったのです!
    やらなくても、以前は問題なく発信・着信できていて、ポート2にfusion-IP を登録してますが完全に正常。

    Updateの意味はよくわかりませんが、これをやらないとサーバーへの設定変更ができないのでしょう。

    大変お世話がせいたしました。
    せっかくですので、一点追記しておきますと、「HT80X」の方が同じ音質設定でも少しクリアーです。

    taropii

    返信削除
    返信
    1. うまくいったようで何よりです。

      HT701 のマニュアルによれば設定をしたあと [Update] [Apply] として設定を[保存]・[適用]となります。

      最終的には [Reboot] で反映されます。
      [Update] は設定内容の[保存]です。

      HT80x の方が音質はよいとのこと、了解です。

      削除
  6. 根が深かったです。

    一応、バイク野郎さんの以下関係の設定をデフォルトに戻したら、同じトラブルが発生しました。
    よって、バイク野郎さんの設定にしています。すると完全に正常応答です。
    電話関係の設定に関しては、私には全くわかりません。
    ありがとうございました。

    taropii
    ------------------------------
    Preferred DTMF method
    Priority 1:
    Priority 2:
    Priority 3:

    Preferred Vocoder
    choice 1:
    choice 2:
    choice 3:
    choice 4:
    choice 5:
    choice 6:
    choice 7:
    ------------------------------

    返信削除
    返信
    1. DTMF はトーン信号の扱いで、基本は RFC2833 です。
      通常はこれでいいはずです。

      Vocoder はコーデックで、固定電話は PCMU(G.711μのこと)なので、すべての Choice をこれにします。
      アナログな音声をデジタル信号に変えることをコーデックによって行うのです。
      このコーデックの方式が複数あり、PCMU は代表的なコーデックです。

      携帯電話は GSM ですが固定網(IP電話も固定網と考えて差し支えありません)とは
      PCMU でのやりとりですので、コーデックは PCMU で OK です。
      コーデックが正しくないと通話ができません。
      呼び出しもはねられる場合があります。

      トーン信号は、音声案内などで「xx は1を、yy は2を〜〜」などと
      アナウンスに従って1番のキーを押したりして発生される信号音です。

      これは世界的標準が RFC2833 という規格で定められていて、電話網共通には
      この信号を選択すればまず大丈夫です。

      削除