Jitsi/Docker版のJitsiをAWSのEC2上にインストール

更新日: 2021-03-24 (水) 00:43:23 (81d)

docker-jitsi-meetの準備・設定

$ 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である。

$ 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の仕組み
ICEがどういったものかは以下が参考になる。
https://www.slideshare.net/iwashi86/webrtcice

セキュリティグループ

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

インバウンド

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用

コンテナの起動

$ docker-compose up -d
$ docker-compose logs -f

2名以上の接続でダウンする場合

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

[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

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

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はダミーである)。

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のやり取りを覗くことができる。

chrome://webrtc-internals

setRemoteDescriptionやsetLocalDescriptionを見てみる。

WebRTC_Internals.png

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

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

about:webrtc

WebRTC_Internals-FireFox.png

AWS EC2でTCPのFallbackでICEに失敗する場合

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

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は以下で確認できる。

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を使うので気づきにくい。

Jitsi-ice-harvester-on-ec2.png

参考リンク


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