Jitsi/Docker版のJitsiをAWSのEC2上にインストール のバックアップの現在との差分(No.1)


  • 追加された行はこの色です。
  • 削除された行はこの色です。
#author("2021-03-23T15:27:35+00:00","default:haikikyou","haikikyou")
[[jitsi]]

#author("2021-03-23T15:43:23+00:00","default:haikikyou","haikikyou")
#contents

* docker-jitsi-meetの準備・設定 [#k05f6c33]

#geshi(bash){{{
$ git clone https://github.com/jitsi/docker-jitsi-meet.git
$ cd docker-jitsi-meet
$ ./gen-passwords.sh
$ mkdir -p ~/.jitsi-meet-cfg/{web/letsencrypt,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri}
}}}

env.exampleを.envにコピーして、環境変数を設定する。docker-composeによるコンテナ起動時に読まれる.envである。

#geshi(bash){{{
$ cp env.example .env
$ vi .env
# 設定ファイルを格納するパス
CONFIG=~/.jitsi-meet-cfg

# 外部に公開するノードのポート
HTTP_PORT=80

# 外部に公開するノードのポート
HTTPS_PORT=443

# タイムゾーン
TZ=Asia/Tokyo

# サイトURL、jigasi etherpad
PUBLIC_URL=https://meet.8-teams.xyz/

# ノードのパブリックIPを指定する。これは、ElasticIPで割り当てたパブリックなIP。
# エンドユーザーがアクセスするIP。
# ノードのローカルアドレスとパブリックアドレスの静的なマッピングでICE候補として使用される。
# ローカルアドレスは、jvb実行時にコンテナのipアドレスに解決される。
DOCKER_HOST_ADDRESS=<Public IP>

# Let's Encryptを有効
ENABLE_LETSENCRYPT=1

# サービスドメイン
LETSENCRYPT_DOMAIN=meet.example.com

# ドメインオーナー
LETSENCRYPT_EMAIL=owner@example.com

# STUN server
# JVBのパブリックIPをdetectするのに使う
#JVB_STUN_SERVERS=meet-jit-si-turnrelay.jitsi.net:443

# JVBのUDPポート
JVB_PORT=10000

# TCP Fallbackの設定、UDPが使えない時にTCPを使用
JVB_TCP_HARVESTER_DISABLED=false
JVB_TCP_PORT=4443
JVB_TCP_MAPPED_PORT=4443
}}}

ドメインなどは自身の環境に合わせて読み替える。

参考)ICEの仕組み&br;
ICEがどういったものかは以下が参考になる。&br;
https://www.slideshare.net/iwashi86/webrtcice

* セキュリティグループ [#z5b6220b]

セキュリティグループを設定する。Network ACLもある場合はそちらも穴を開けておく。

''インバウンド''

#geshi{{{
80	TCP	0.0.0.0/0
22	TCP	<myip>
4443	TCP	0.0.0.0/0
443	TCP	0.0.0.0/0
10000   UDP     0.0.0.0/0
}}}

- 80/HTTP、443/HTTPはWeb、BOSH用(Jabber/XMPPで必要、HTTPでXML形式のXMPPメッセージをやり取りする)。
- 10000/UDPはメディアストリーム用
- 4443/TCは10000/UDPが失敗する場合のfallback用

* コンテナの起動 [#o5e67cea]

#geshi(bash){{{
$ docker-compose up -d
$ docker-compose logs -f
}}}

* 2名以上の接続でダウンする場合 [#pf3f1c9b]

設定にエラーがなければ起動までは問題なく動作するはずである。だが、2名以上で接続した場合、つまりP2PやJVB経由の通信でビデオや音声データの送受信が上手くできないケースがある。そのような場合、ブラウザの開発ツールでコンソールログを見ると(Win: F12、mac: Command + ALT + i)、以下のようなエラーが見えるかもしれない。この場合は、シグナリングに失敗している可能性が高い。ファイアウォールやSTUN、harvesterのマッピングを疑ってみる。ファイアウォールで問題なければ、ICE Candidatesをチェックしてみる。

#geshi{{{
[modules/RTC/BridgeChannel.js] <l._send>:  Bridge Channel send: no opened channel.
[JitsiConference.js] <u.sendMessage>:  Failed to send E2E ping request or response. undefined
}}}

[[ファイル:Jitsi-no-opened-channel-error.png|border]]
&ref(./Jitsi-no-opened-channel-error.png,100%);

サーバ側では以下のようなPair failedのエラーが複数行に渡って出力され、succeededと表示されることなくPairの検証が終わっている。

#geshi{{{
jvb_1      | INFO: Pair failed: 172.18.0.5:10000/udp/host -> 172.42.42.1:62455/udp/host (stream-020963df.RTP)
}}}

上手くPairを見つけられるとsucceededというログを確認できる(以下ログのIPはダミーである)。

#geshi{{{
jvb_1      | INFO: Pair succeeded: 1.2.3.4:10000/udp/srflx -> 5.6.7.8:63453/udp/prflx (stream-32a4725d.RTP).
jvb_1      | Sep 23, 2020 9:02:16 PM org.jitsi.utils.logging2.LoggerImpl log
jvb_1      | INFO: Pair validated: 1.2.3.4:10000/udp/srflx -> 5.6.7.8:63453/udp/prflx (stream-32a4725d.RTP).
jvb_1      | Sep 23, 2020 9:02:16 PM org.jitsi.utils.logging2.LoggerImpl log
jvb_1      | INFO: IsControlling: true USE-CANDIDATE:true.
jvb_1      | Sep 23, 2020 9:02:16 PM org.jitsi.utils.logging2.LoggerImpl log
jvb_1      | INFO: Nomination confirmed for pair: 1.2.3.4:10000/udp/srflx -> 5.6.7.8:63453/udp/prflx (stream-32a4725d.RTP).
jvb_1      | Sep 23, 2020 9:02:16 PM org.jitsi.utils.logging2.LoggerImpl log
jvb_1      | INFO: Selected pair for stream stream-32a4725d.RTP: 1.2.3.4:10000/udp/srflx -> 5.6.7.8:63453/udp/prflx (stream-32a4725d.RTP)
}}}

ブラウザがChromeの場合、URLフィールドに以下を入力することでWebRTCのやり取りを覗くことができる。

#geshi{{{
chrome://webrtc-internals
}}}

setRemoteDescriptionやsetLocalDescriptionを見てみる。

[[ファイル:WebRTC Internals.png|700px|border]]
&ref(./WebRTC_Internals.png,100%);

参考)WebRTCデバッグ&br;
https://qiita.com/yusuke84/items/8d232c8d24156f16e8ba

FireFoxの場合は以下。FireFoxの場合は、ICE候補ペアの検証結果がわかりやすい。

#geshi{{{
about:webrtc
}}}

[[ファイル:WebRTC Internals-FireFox.png|600px|border]]
&ref(./WebRTC_Internals-FireFox.png,100%);

* AWS EC2でTCPのFallbackでICEに失敗する場合 [#u83abcf1]

UDPが使用できないケースで4443/TCPにFallbackさせようとするが上手くいかない。その場合、以下を有効にすると上手くtcpの候補のPairを検証してくれた。

#geshi{{{
org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
}}}

jvbには、AwsCandidateHarvesterというHarvesterがあり、自動でLocalとPublic IPのマッピングをしてくれるが、これを無効化する。

https://github.com/jitsi/ice4j/blob/master/src/main/java/org/ice4j/ice/harvest/AwsCandidateHarvester.java

PublicとPrivateのIPは以下で確認できる。

#geshi{{{
ec2-user@ip-172-31-4-172$ curl http://169.254.169.254/latest/meta-data/local-ipv4
172.31.4.172
ec2-user@ip-172-31-4-172$ curl http://169.254.169.254/latest/meta-data/public-ipv4
x.x.x.x
}}}


TCPのICE Candidatesを生成するTcpHarvesterで、AwsCandidateHarvesterにより静的に設定したMappingが上書きされているように見える。EC2のインターフェースに設定されているプライベートアドレスとパブリックIPがマップされており、DockerコンテナのIPがマスクされてしまう。よって、EC2上でDockerでjitsiを動作させる場合は注意する。通常はudpを使うので気づきにくい。

- https://github.com/jitsi/ice4j/blob/v3.0/src/main/java/org/ice4j/ice/harvest/TcpHarvester.java#L223
- https://github.com/jitsi/ice4j/blob/v3.0/src/main/java/org/ice4j/ice/harvest/TcpHarvester.java#L267

[[ファイル:Jitsi-ice-harvester-on-ec2.png|600px|border]]
&ref(./Jitsi-ice-harvester-on-ec2.png,100%);

* 参考リンク [#k4a1cda1]

- https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker
- https://github.com/jitsi/docker-jitsi-meet
- https://www.slideshare.net/iwashi86/webrtcice
- https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md
- https://qiita.com/massie_g/items/f5baf316652bbc6fcef1
- https://qiita.com/yusuke84/items/8d232c8d24156f16e8ba
- [https://support.skyway.io/hc/ja/articles/236031388-TURN%E3%82%B5%E3%83%BC%E3%83%90%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%A6%E6%8E%A5%E7%B6%9A%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%81%8B%E7%A2%BA%E8%AA%8D%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6 TURNサーバを利用して接続しているか確認する方法について - SkyWay]
- [https://www.amazon.co.jp/dp/4897979587/ WebRTC ブラウザベースのP2P技術 (日本語) 単行本(ソフトカバー)– 2014/12/12]



トップ   一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
目次
TOP | 閉じる | ダブルクリックで閉じる