当サイトをご利用の場合は、すでにサイト側で事前設定が完了しています。このガイドは、Discourse をセルフホストしている管理者向けです。
Discourse Voice は、音声およびビデオ通話に WebRTC を使用します。参加者が直接接続できるよう支援するために、パブリックな STUN サーバーが同梱されています。管理者はこれらのサーバーを置き換え、直接接続が失敗するネットワークをサポートするために TURN を追加できます。
コミュニティ専用のサーバーの場合、共有シークレット認証を使用し、STUN 設定を空にする TURN を推奨します。 これにより、永続的な TURN パスワードを配布することなく、パブリックアドレスの検出とリレーによるフォールバックを提供します。
このガイドは、Voice のピアツーピア通話に適用されます。LiveKit を使用しているルームは、代わりに LiveKit 独自の ICE/TURN 設定を使用します。Voice の LiveKit 設定について学ぶ。
STUN と TURN は何をするのか？
- STUN は、ブラウザがパブリック IP アドレスとポートを発見し、直接接続を試みるのを助けます。
- TURN は、直接接続を確立できない場合にメディアを中継します。
認証済みの TURN アロケーションは、ブラウザのパブリックアドレスも返します。WebRTC はこれを サーバーリフレクティブ候補 (server-reflexive candidate) として使用でき、個別の STUN サーバーなしで STUN のアドレス検出の利点を提供します。TURN 仕様。
共有シークレット TURN が設定されている場合、Voice は STUN 設定が空であっても、直接接続とリレー接続の両方を許可します。TURN サーバーのみを設定しても、すべての通話がリレーを強制されるわけではありません。 Voice の ICE 設定。
1. TURN サーバーの準備
TURN REST API 共有シークレット認証をサポートするマネージド TURN サービスを使用するか、coturn を自分で実行できます。
セルフホスト環境の場合、以下の準備をしてください：
- 中継通話に十分な帯域幅とパブリック IP アドレスを持つサーバー。
- そのサーバーを直接指す
turn.example.comのようなホスト名。 - TURN リスナーおよび UDP リレーポート範囲へのファイアウォールアクセス。
- TURN を TLS 経由で提供する場合の有効な証明書。
参加者のブラウザは TURN に直接接続します。通常の HTTP リバースプロキシや CDN プロキシでは TURN トラフィックを運ぶことはできません。
coturn 設定の例
ランダムなシークレットを生成します：
openssl rand -hex 32
結果は秘密にしてください。coturn と Discourse に同じ値を入力します。
直接パブリック IP が割り当てられているサーバーでは、/etc/turnserver.conf に以下の内容をスタートポイントとして使用します：
listening-port=3478
fingerprint
realm=turn.example.com
use-auth-secret
static-auth-secret=REPLACE_WITH_YOUR_RANDOM_SECRET
# スタンドアロン STUN リクエストを無効化します。
# 認証済みの TURN アロケーションは依然としてクライアントのパブリックアドレスを返します。
no-stun
min-port=49152
max-port=65535
no-multicast-peers
# この例では TLS なしで開始します。
no-tls
no-dtls
ホスト名とシークレットを置き換え、設定ファイルを保護し、coturn を再起動してください。競合する no-auth や静的な user= 設定があれば削除してください。coturn の共有シークレットモードは、内部で必要な認証メカニズムを有効にします。Coturn 設定リファレンス。
以下の入站トラフィックを許可してください：
| ポート | プロトコル | 目的 |
|---|---|---|
3478 |
UDP および TCP | ブラウザからの TURN への接続 |
49152–65535 |
UDP | 中継されたメディア |
対応する出站トラフィックも許可してください。リレー範囲は min-port および max-port と一致する必要があります。
サーバーが NAT の背後にある場合、coturn の external-ip=PUBLIC_IP/PRIVATE_IP マッピングを設定し、リスナーポートとリレーポートをフォワードしてください。リレーポートは NAT を通過する際にポート番号を保持する必要があります。Coturn デプロイオプション。
制限的なネットワーク向けに TLS を追加する
TLS 経由の TURN は、UDP がブロックされているネットワークの参加者に対して別の接続オプションを提供します。
no-tls を削除し、以下を設定します：
tls-listening-port=5349
cert=/path/to/fullchain.pem
pkey=/path/to/privkey.pem
5349/TCP を開き、coturn が証明書と鍵を読み取れることを確認し、証明書更新後に再起動してください。
TURN サーバーでそのポートが利用可能な場合、代わりに 443/TCP を使用できます。これは制限的なネットワークで役立つ場合がありますが、一部のネットワークではポート 443 上の非 HTTP トラフィックも検査・ブロックします。ブラウザが TCP または TLS 経由で TURN に到達する場合でも、UDP リレー範囲は依然として必要です。Coturn サーバードキュメント。
2. Discourse の設定
管理画面 → 設定 で、これらの Voice 設定を検索します：
| 設定 | 値 |
|---|---|
voice_stun_servers |
空 — デフォルトエントリを削除 |
voice_turn_secret |
coturn の static-auth-secret に使用した値 |
voice_turn_secret_servers |
| で区切られた TURN URI |
voice_turn_servers |
空 |
voice_turn_username |
空 |
voice_turn_credential |
空 |
上記の設定の場合、voice_turn_secret_servers には以下を入力します：
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp
TLS を有効にした場合、そのエンドポイントを追加します：
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp|turns:turn.example.com:5349?transport=tcp
// なしの turn: および turns: URI を使用してください。サーバーが実際にサポートするエンドポイントのみをリストアップしてください。
voice_turn_secret_servers リストは、共有シークレットから生成された認証情報を使用します。別の voice_turn_servers リストは、固定のユーザー名とパスワードを使用します。Voice 設定定義。
設定を保存し、参加者に通話から離脱して再参加してもらい、新しい設定を取得させます。
3. セットアップの確認
家庭用ブロードバンドとモバイルデータなど、異なるネットワークの 2 人の参加者でテストしてください。双方向で音声動作を確認し、その後、ビデオと画面共有をテストします。
Chromium ベースのブラウザでは、参加前に chrome://webrtc-internals を開きます：
srflx候補は、発見されたパブリックアドレスを表します。relay候補は、利用可能な TURN リレーを表します。- 選択された候補ペアは、実際にメディアを運んでいる接続を示します。
成功した直接通話は、リレーが動作することを証明しません。 TURN を必要とするネットワークからもテストするか、iceTransportPolicy: "relay" と一時的な認証情報を持つ WebRTC テストクライアントを使用してください。
coturn のログを確認し、認証済みのアロケーションが成功していることを確認します。有効な認証情報がないリクエストは、リレーアロケーションを取得してはいけません。最初の 401 認証チャレンジは正常ですが、繰り返し発生する認証失敗は調査が必要です。
サーバーをコミュニティ専用に保つ
共有シークレットは Discourse と TURN サーバー上に保持されます。参加者には一時的な認証情報が渡されます。Voice は現在、アロケーション作成に 12 時間有効な認証情報を生成します。確立されたアロケーションは、更新されている間継続できます。Voice の認証情報生成。
これにより、匿名のオープンリレーを防ぐことができますが、TURN 認証情報はブラウザのオリジンに紐付けられていません：参加者は一時的な認証情報をコピーして再利用できます。悪用を制限するために：
- Voice のアクセスを意図されたグループに制限する。
- リレー帯域幅とアロケーション数を監視する。
- コミュニティに適した coturn のアロケーションクォータと帯域幅制限を設定する。
- TURN ホストから到達可能なプライベート、リンクローカル、その他の内部宛先へのリレーアクセスをブロックする。
- coturn を最新に保ち、共有シークレットが漏洩した場合にローテーションする。
この Discourse デプロイメント用に専用のシークレットを使用してください。no-stun を有効にすると、サーバーは匿名のスタンドアロン STUN サービスを提供することも停止します。Coturn 認証とアクセス制御。
代替手段
パブリック STUN サーバーのみを置き換える
voice_stun_servers を、| で区切った独自の STUN URI に設定します：
stun:stun.example.com:3478
リレーを必要としない場合は、TURN 設定を空にしてください。STUN だけでは、すべてのネットワークで通話を機能させることはできません。no-stun で設定された coturn サーバーでは、このエンドポイントを提供できません。
固定のユーザー名とパスワードで TURN を使用する
プロバイダーが共有シークレット認証をサポートしていない場合、voice_turn_servers、voice_turn_username、voice_turn_credential を設定します。共有シークレット設定は空にしてください。
参加者にはこれらの固定認証情報が渡されるため、サイト外での再利用が容易になります。また、Voice は現在、静的な TURN サーバーが設定され、STUN リストが空の場合に、リレー接続を強制します。プロバイダーがサポートしている場合は、共有シークレット認証を優先してください。Voice の ICE 設定。