回線を変えると/peersが403エラーを返す

Comments

9 comments

  • Avatar
    Toshiya Nakakura

    ドキュメントがわかりづらくて恐縮ですが、403 Errorは他の事象でも発生します。
    例えば以下のような場合にも発生します。

    - インターネットへ接続されておらずSkyWay Serverと通信できない場合
    - peer objectを開放(delete methodのcall)を行わず連続して同じpeer_idでpeer objectを作成しようとした場合

    今回回線を変更されて発生したということですので、SkyWayサーバへの接続が正常に確立できていないのではないかと思われますので、インターネットへの接続, DNS, Firewall等をご確認頂くのが良いのではないかと思います。

     

    0
    Comment actions Permalink
  • Avatar
    greennote

    ありがとうございます。gatewayから外(skywayのサーバー、という理解でよろしいでしょうか)への通信ができない場合も403を返す、ということですね。

    確認してみましたが、例えばwebrtc.ecl.ntt.comに対してpingを打つとアドレス解決が正常に完了し、100%でping送信が成功します。ですので、インターネットへの接続およびDNSへのアクセスには問題がないように思えます。レイテンシも300ms程度ですので、3G回線としては通常の値かと思われますので、特に応答に時間が掛かっている様子もありません。

    装置側には特にFirewallは入っていませんが、網側で何かしらのフィルタリングが行われている可能性は否定できません。この場合、どの宛先に対してどのポートで送受信できることが必要でしょうか?

    0
    Comment actions Permalink
  • Avatar
    greennote

    gatewayがサーバと行う通信を調べてみたのですが、まずpeersが成功する場合にはGatewayから153.153.*.*のようなNTT Communication様保有のアドレスに対し443/tcpでコネクションが張られることを確認しました。

    一方、peersが失敗する場合にはこのコネクションが張られないようです。そこでcurl -k https://153.153.*.*としてみると、404エラーにはなりますが正常に通信を行うことができることが確認できました。

    従って、Gatewayを起動してからサーバへのhttpsコネクションが張られるまでの間に何か失敗していると思われるのですが、今のところ状況がつかめておりません。

    0
    Comment actions Permalink
  • Avatar
    Toshiya Nakakura

    調査いただきました通り、SkyWayのClientはSkyWayサーバとsocket.ioライブラリを用いて443番で通信しております。

    ここまで調べていただいた情報を元に考えますと、遅延が関係している気がします。別件であった事象なのですが、遅延が大きい回線で通信を行うとエラーが発生することがあるようです。REST APIのアクセスに対して応答するまでの時間でSkyWayサーバへの通信が完了しない場合エラーが発生するようです。

    お手数おかけいたしますが、Timeoutまでの時間を伸ばしたversion 0.0.3を試して頂けますでしょうか。

    https://github.com/skyway/skyway-webrtc-gateway/blob/master/release-notes.md

     

    0
    Comment actions Permalink
  • Avatar
    greennote

    ありがとうございます。既に0.0.3を使用しており、MD5値もgateway_linux_arm: e25b08a3afbeb3374e64a8c2e47d81b3 で一致しておりますので間違いないと思います。

    /peersを発行してからエラーが返るまでの時間は6秒弱で、0.0.3の仕様である30秒タイムアウトとは整合していません。またcurl -k https://153.153.*.* は1秒未満で404を返します。

    0
    Comment actions Permalink
  • Avatar
    Toshiya Nakakura

    30秒タイムアウトはイベントのLong Pollのケースで、その他のケースについては数秒程度でタイムアウトが帰るため、仕様通りの動作ですが、6秒ほど経過しているということであれば時間超過の線は仰るとおり考えづらいですね。

    既知の事象になく、新規発見の事象のように思われます。弊社でも確認をしてからお返事する形でよろしいでしょうか。即答できず少しお時間頂くことになるかと思います。お手数おかけして申し訳ありませんがよろしくお願いいたします。

    0
    Comment actions Permalink
  • Avatar
    greennote

    承知いたしました。お手数お掛けしますがよろしくお願いいたします。何か調査にご協力できることがありましたらご遠慮なくお問い合わせください。

    0
    Comment actions Permalink
  • Avatar
    greennote

    その後いかがでしょうか? 3G経由での利用が(当面)難しいようであれば別の方法を考えたいと思います。

    0
    Comment actions Permalink
  • Avatar
    Toshiya Nakakura

    おまたせしており申し訳ありません。本件弊社環境で再現せず、ひとまずログの詳細化を進めているところです。

    ただ、3Gに限らずですが、パケットロスのある環境下での映像転送はノイズが激しく実用に耐えないのではないかと思われます。現在エンドユーザプログラムからRTCP制御が行えるように実装中ですが、そちらが完了するまではおすすめできません。

    用途次第ですが、別環境での利用が可能なのであればそちらをお勧めいたします。

    0
    Comment actions Permalink

Please sign in to leave a comment.