Direct Mediaが失敗した場合にNextcloud Talkの通話を繋ぐ方法

接続できない、またはメディアが一方通行になっている Nextcloud Talk 通話を修正するには、到達可能な TURN リレーを設定し、Talk 設定でそのホスト名、ポート、および共有シークレットを入力して、TURN リスナーとそのリレー ポートの両方を経由するトラフィックを許可します。TURN は、直接接続が失敗した場合に WebRTC にリレー ルートを提供しますが、弱い Wi-Fi、パケット ロス、または過負荷のネットワークを修復するものではありません。

具体例：オフィスからはTalk通話に参加できるものの、ホテルのネットワークからはビデオを確実に送信できない小規模な組織を想像してみてください。ホテルのファイアウォールが直接メディアパスをブロックしている可能性があります。以下の例では、管理者がルートを確認し、coTURNを設定し、変更をテストする様子を示しています。これは実際の導入やテストのレポートではありません。

1. リレーが適切な解決策であることを確認する

Nextcloud Talkはまず、参加者同士を直接接続しようとします。STUNは、ルーターによって作成された公開アドレスとポートをデバイスが検出するのに役立ちます。ファイアウォールや制限的なNATによって直接接続が妨げられる場合、TURNがメディアを中継します。STUNサーバー単独ではこの中継機能を提供できません。

オフィスネットワーク上の通話と、スマートフォンのホットスポットなど別のネットワークからの通話を比較してください。ある場所では通話が接続できるものの、制限のある場所では音声や映像が繰り返し確立できない場合は、TURNを次に確認するのが妥当です。通話は接続できるものの、どのネットワークでも音声がぼやけたり途切れたりする場合は、まず帯域幅、パケット損失、Wi-Fi品質、CPU負荷を測定してください。リレー経由でより多くのメディアをルーティングすると負荷が増加するだけで、容量が増えるわけではありません。

Talkのバージョン、TURNホスト名とポート番号、TURNホストがNATの背後にあるかどうか、および高性能バックエンド（HPB）がインストールされているかどうかを記録してください。秘密情報は厳重に保管してください。以下のコマンドはsystemdが動作するLinuxを前提としています。パッケージパスは環境によって異なります。

2. coTURNを共有シークレット認証で設定する

NextcloudのTalkドキュメントでは、古いリリースにはIPv6 UDPソケットの問題があるため、coTURN 4.5.0.8以降を推奨しています。ディストリビューションのリポジトリからインストールし、アクティブな設定ファイル（多くの場合/etc/turnserver.conf）を見つけます。TURNホストでランダムなシークレットを生成します。

openssl rand -hex 32

その値をパスワードマネージャーまたは保護された構成ストアに保存します。アクティブなcoTURN構成で、リスナー、共有シークレット認証、およびレルムを設定します。例のホスト名とシークレットを実際の値に置き換えてください。

listening-port=3478
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_RANDOM_SECRET
realm=turn.example.org
total-quota=0
bps-capacity=0
stale-nonce
no-multicast-peers

Talkのドキュメントにlt-cred-mechは、coTURNバージョン4.5.0.8より前のバージョンに関する情報しか記載されていません。古いインストール環境の場合は、既存の設定をそのままコピーするのではなく、アップグレードしてください。coTURNがNAT環境下にある場合は、導入ガイドの指示に従ってパブリックアドレスとリレーアドレスを設定し、DNS名が参加者がアクセス可能なアドレスに解決されることを確認してください。

3. リスナーとリレーパスを開く

UDPとTCPの場合、TURNリスナーポート（この例では3478）をホストファイアウォールとアップストリームファイアウォールで許可します。TLSの場合、coTURNには有効な証明書と秘密鍵も必要で、Talkはを使用する必要がありますturns:。ポート443はより制限の厳しいネットワークにも到達できますが、競合がないか確認してください。HPBもそのポートを必要とする場合があり、その場合は別のIPアドレスまたはホストが必要になります。

メディアもリレーポートを使用します。ホストファイアウォール、クラウドセキュリティグループ、およびルーターでcoTURNリレーUDP範囲を許可してください。min-portと を設定している場合はmax-port、その範囲を正確に開いてください。リスナーのみを許可するだけでは不十分です。NATの背後にあるTURNホストの場合は、リスナーとリレー範囲の両方を転送し、パブリック/リレーアドレスを設定してください。無関係な内部サービスへのアクセスを防ぐために、coTURNピア制限を維持してください。

編集後、coTURNを再起動し、サービスがアクティブであることを確認してください。例えば、systemdホストの場合：

sudo systemctl restart coturn
sudo systemctl status coturn --no-pager

サービスステータスはプロセスが開始されたことを示しますが、リモートブラウザがリレーに到達できることを証明するものではありません。ホストとプロバイダのファイアウォールをそれぞれ確認し、coTURNログでバインドエラー、認証失敗、または割り当てクォータメッセージを確認してください。

4. Talkにサーバーを追加し、実際の通話を確認します。

管理者として、[管理設定] > [トーク]を開きます。TURN ホスト名とポート (例: ) とturn.example.org:3478、 と同じシークレットを入力します。ホスト名フィールドに、、 、 をstatic-auth-secret含めないでください。トークのコントロールでスキームを選択します。可能な限り UDP と TCP を有効にしておきます。coTURNで TLS を設定した後でのみ使用してください。https://turn:turns:turns:

Talkの組み込みTURNチェックが利用可能であれば、保存して実行してください。次に、制限のあるネットワークから別のネットワークに発信し、双方向の音声とビデオを確認します。通話中にcoTURNログを確認し、割り当てまたは認証の失敗がないか確認してください。この例では、管理者がホテルのような接続とオフィスでの通話を比較しています。

チェックが失敗した場合は、ホスト名、ポート、シークレットを比較し、DNS、ファイアウォールルール、リレーUDP範囲、NAT転送、およびサービスログを確認してください。基本的なチェックではリレーパスの問題を見落とす可能性があるため、外部ネットワークからテストしてください。TURNのみの診断については、Talkのブラウザ固有の手順に従ってください。コンソールでの方法は一時的なものであり、ブラウザによって動作が異なります。

TURNはグループ通話のスケーリングに対応していません。Nextcloudによると、5～10人を超えるグループでの通話にはHPBが必要です。TURNが接続されてもビデオ品質が悪い場合は、リレークォータを変更する前に、帯域幅、パケットロス、Wi-Fi干渉、サーバー負荷を確認してください。

検証

この修正は、以下の3つの兆候によって裏付けられます。通話がTURN構成を受け入れること、coTURNログに通話中のリレー割り当てが表示されること、そして異なるネットワーク上の参加者が双方向で音声とビデオを交換できることです。オフィス通話のみが機能する場合、またはログに着信要求が表示されない場合は、パブリックルートがブロックされているか、設定されているホストとポートが一致していません。メディアは流れるものの、品質が低い場合は、TURN接続は機能しており、残りの問題はネットワークまたは通話インフラストラクチャの別の場所にあると考えられます。

参考資料: Nextcloud Talk TURN サーバー設定; Nextcloud Talk coTURN 設定; coTURN 設定 wiki。