# 本番稼働に向けて この資料はチュートリアルで Sora をなんとなく体験したあとに、 本番環境に向けてどのような準備が必要なのか、どの機能を使っていけばいいのかをまとめたものです。 > **重要** > > 不明点などはサポートまでお問い合わせください。 ## 優先順位 Sora で外部から指定する値には優先順位があります。 上から順に優先度が高く、同じ優先度の場合は後から指定した値が優先されます。 1. セッション生成時の払い出しで指定した値 2. 認証成功時の払い出しで指定した値 3. シグナリング接続時に指定した値 4. sora.conf で設定した値 - sora.conf で設定した値は、シグナリング接続時の値で上書きできます - シグナリング接続時の値は、認証成功時の払い出しで上書きできます - 認証成功時の払い出しは、セッション生成時の払い出しで上書きできます 本番環境ではシグナリング接続時の値を利用するのは避けて、 認証成功時やセッション生成時の値を利用するようにしてください。 ## IPv4 アドレスの固定 `sora.conf` の [ipv4_address](SORA_CONF.html#04becc) にサーバーの IP アドレスを指定してください。 ```ini ipv4_address = 192.0.2.10 ``` ## IPv6 アドレスの利用について Safari は IPv6 環境での動作が不安定なため、 Safari をターゲットデバイスに含んでいる場合は `sora.conf` の IPv6 設定を無効にする `ipv6 = false` を推奨しています。 ファイアーウォールを利用される場合は IPv6 向け設定もご確認ください。 ## sora.conf の turn_fqdn を設定する iOS の場合は TURN は FQDN を利用しないと接続ができない場合があるため、 TURN-UDP / TURN-TCP で利用するドメインを指定してください。 `sora.conf` の `ipv4_address` に指定した IP アドレスを設定してある FQDN を指定してください。 ```ini turn_fqdn = sora-turn.example.com ``` ## ウェブフックなどで利用する CA 証明書のインストール もしウェブフックなどで HTTPS サーバへのアクセスを行う場合に、 自前で CA 証明書を設定しない場合、信頼された CA 証明書のインストールを行ってください。 - Ubuntu は `apt install ca-certificates` でインストールされる証明書を利用します - RHEL (または CentOS) は `dnf install ca-certificates` でインストールされる証明書を利用します ### 影響を受ける機能 - 認証ウェブフック - セッションウェブフック - イベントウェブフック - 統計ウェブフック - 音声ストリーミング機能 ただし、以下の設定で自前で CA 証明書を指定している場合は、この影響を受けません。 - [webhook_tls_verify_cacert_file](SORA_CONF.html#7036dc) - [audio_streaming_tls_verify_cacert_file](SORA_CONF.html#feef99) ## HTTP API のループバックアドレスからのみのアクセス > **重要** > > この設定を導入することを強く推奨します Sora の HTTP API は TLS を利用したセキュアな通信機能や認証機能を持ち合わせていません。 そのため、本番環境では `sora.conf` の [api_loopback_address_only](SORA_CONF.html#9d6140) の値を `true` にしてください。 こうすることでループバックアドレスからのみ HTTP API が叩けるようになります。 アプリケーションからの HTTP API へのアクセスは Nginx などのリバースプロキシ経由で利用してください。 ## シグナリングのループバックアドレスからのみのアクセス > **重要** > > この設定を導入することを強く推奨します Sora の WebSocket は TLS を利用したセキュアな通信機能を持ち合わせていません。 そのため、本番環境では `sora.conf` の [signaling_loopback_address_only](SORA_CONF.html#e22105) の値を `true` にしてください。 こうすることでループバックアドレスからのみシグナリングが叩けるようになります。 WebRTC クライアントからシグナリングへのアクセスは Nginx などのリバースプロキシ経由で利用してください。 ## ファイルディスクリプタ数の設定 Sora は 1 接続で少なくとも 2 つ以上のファイルディスクリプタを利用します。 また、ウェブフックやログの書き込みでも追加でファイルディスクリプタを利用します。 同時接続数が 100 の場合は Linux のデフォルト値である 1024 でも足りるとは思いますが、 ある程度大きめのファイルディスクリプタ数に変更してください。 ## systemd の適用 > **重要** > > この仕組みを導入することを強く推奨します Sora の起動/停止に `bin/sora daemon` を利用するのではなく systemd を適用してください。 デーモン化せずに Sora を動かすには `bin/sora foreground` を利用します。 詳細は [systemd](SYSTEMD.html) をご確認ください。 ## TURN-TLS、TURN-TCP、シグナリングで 443 番ポートを使用する > **重要** > > この仕組みを導入することを強く推奨します。 > この設定は Sora 2021.1 以降に最適化されています。 > **注意** > > NGINX および systemd の設定に関する質問については Sora のサポート範囲外となります。 **この設定はある程度の NGINX や証明書の知識が必要になります** NGINX のバージョンは 1.11.5 以降が必須です。 TURN-TLS、TURN-TCP、シグナリング（HTTPS）を 443 番ポートのみで受信する場合は次の設定を追加してください。 > **注意** > > NGINX の停止に QUIT シグナルを使用している場合は、nginx 起動時に作成された UNIX domain socket のソケットファイルは削除されないため、nginx の再起動に失敗します。 > そのため、サービス停止を QUIT シグナルではなく TERM シグナルを使用するように変更するか、または、daemon off で起動することをお勧めします。 > systemd を使用している場合も、ドロップインファイル等を作成して、nginx 停止時のシグナルを QUIT シグナルから TERM シグナルへ変更するか、daemon off による管理へ変更することをお勧めします。 ### NGINX のストリーム機能と ssl_preread 機能を利用する > **ヒント** > > Ubuntu 24.04 では NGINX のストリーム機能は `apt install libnginx-mod-stream` で明示的にインストールする必要があります。 NGINX の機能を利用して、同一ポートの待受で複数のプロトコルを扱えるようにします。 その機能を利用した NGINX の参考設定です。証明書には Let's Encrypt を利用している想定です。 利用する証明書はマルチドメイン (SANs) またはワイルドカード証明書が前提となります。 - sora.example.com- シグナリングの WebSocket over TLS で利用するドメイン - sora-turn.example.com- TURN-TLS で利用するドメイン ```nginx stream { # SNI のサーバー名が取得できない場合、または、該当するサーバー名が指定されていない場合は TURN-TCP へ # 該当するサーバー名が指定されている場合は TURN-TLS または シグナリングへ map $ssl_preread_server_name $upstream { default sora-turn.example.com; "sora-turn.example.com" unix:/tmp/tls.sock; "sora.example.com" unix:/tmp/https.sock; } # Sora の TURN-TCP へ転送 upstream sora-turn.example.com { # Sora の TURN-TCP へ # ここの IP アドレスは Sora の ipv4_address に指定した値を指定してください # ここを 127.0.0.1 にすると Firefox で繋がらなくなることを確認しています server 192.0.2.1:3478; } # TURN-TCP, TURN-TLS, シグナリングを TCP で待ち受け server { listen 443; # IPv6 を利用している場合は下記を有効にしてください # listen [::]:443; proxy_pass $upstream; proxy_protocol on; ssl_preread on; } # TURN-TLS, シグナリングの TLS 終端し TURN-TCP へ転送 server { listen unix:/tmp/tls.sock ssl proxy_protocol; # SNI を見て TURN-TLS の場合は TURN-TCP へ転送 # シグナリング（HTTPS）の場合は HTTP へ転送 proxy_pass $ssl_server_name; proxy_protocol on; ssl_certificate /etc/letsencrypt/live/sora.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/sora.example.com/privkey.pem; ssl_protocols TLSv1.2; ssl_prefer_server_ciphers on; ssl_handshake_timeout 10s; ssl_session_cache off; ssl_session_tickets off; } } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; gzip on; # $proxy_protocol_addr を利用することでクライアントの IP が保持できるようになる log_format proxy '$proxy_protocol_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"'; # 定義した proxy を利用する access_log /var/log/nginx/access.log proxy; server { listen unix:/tmp/https.sock ssl proxy_protocol; root /var/www/html; index index.html index.htm; ssl_certificate /etc/letsencrypt/live/sora.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/sora.example.com/privkey.pem; ssl_protocols TLSv1.2; ssl_prefer_server_ciphers on; ssl_session_cache off; ssl_session_tickets off; real_ip_header proxy_protocol; server_name sora.example.com; # シグナリングを Sora に Proxy します location = /signaling { proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_pass http://127.0.0.1:5000/signaling; proxy_set_header X-Real-IP $proxy_protocol_addr; proxy_set_header X-Forwarded-For $proxy_protocol_addr; } # Sora の HTTP API に Proxy します # 本番環境では認証などの機能を利用してください location /api { proxy_http_version 1.1; proxy_pass http://127.0.0.1:3000/; } # OBS (WHIP/WHEP) 向けのシグナリングを Sora に Proxy します location ~ ^/(whip|whip-session|whep|whep-session)/ { proxy_pass http://127.0.0.1:5000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Authorization $http_authorization; } # Sora のヘルスチェックに Proxy します # 公開するかどうかは検討してください location /.ok { proxy_http_version 1.1; proxy_pass http://127.0.0.1:5000; } } } ``` TURN-TCP、 TURN-TLS、シグナリングを 443 番で使用する場合の sora.conf の設定は以下になります。 turn_tcp_port, turn_tls_port を 443 に変更します。 ```ini ## TURN 機能を有効にするかどうかを指定してください turn = true ## TURN 機能で利用するレルムを指定してください turn_realm = sora-turn.example.com ## TURN 機能で TURN URL 払い出し機能で利用する FQDN (最後の . なし)を指定してください turn_fqdn = sora-turn.example.com ## TURN 機能で TURN-TCP を有効にするかどうかを指定してください turn_tcp = true ## TURN 機能で TURN-TCP を有効にした際に利用するポート番号を指定してください turn_tcp_listen_port = 3478 ## TURN 機能で TURN-TCP URL 払い出し時のポート番号を指定してください turn_tcp_port = 443 ## TURN 機能で TURN-TLS URL 払い出し機能を有効にするかどうかを指定してください ## オプションでデフォルトは false です turn_tls = true ## TURN 機能で TURN-TLS URL 払い出し機能で利用する FQDN (最後の . なし)を指定してください ## turn_tls_fqdn は turn_fqdn の値を上書きします turn_tls_fqdn = sora-turn.example.com ## TURN 機能で TURN-TLS URL 払い出し機能を有効にした際に利用するポート番号を指定してください turn_tls_port = 443 ``` ### Ubuntu の Nginx で Unix Domain Socket を利用する際の注意点 - SIGTERM を利用するようにしないと、リスタートすることができません - セキュリティアップデートで強制的に apt upgrade が行われた際、 Unix Domain Socket ファイルが残って Nginx が再起動でき無くなる場合があります ```console $ sudo systemctl edit nginx.service ``` ```ini [Service] ExecStartPre= # 起動前に /tmp/tls.sock を削除する設定を追加 ExecStartPre=/bin/rm -f /tmp/tls.sock # 起動前に /tmp/https.sock を削除する設定を追加 ExecStartPre=/bin/rm -f /tmp/https.sock ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;' ExecStop= ExecStop=-/sbin/start-stop-daemon --quiet --stop --signal TERM --pidfile /run/nginx.pid ``` - `ExecStartPre=` を追加して、 既存の `ExecStartPre=` の設定をクリアしてください - `ExecStartPre=/bin/rm -f /tmp/tls.sock` を設定してください - `ExecStartPre=/bin/rm -f /tmp/https.sock` を設定してください - `ExecStop=` を追加して、既存の `ExecStop=` の設定をクリアしてください - `ExecStop=-/sbin/start-stop-daemon --quiet --stop --signal TERM --pidfile /run/nginx.pid` を設定してください。 その後、以下のコマンドを実行してください。 ```console $ sudo systemctl daemon-reload $ sudo systemctl restart nginx ``` ## ウェブフックを NGINX 経由で送信する Sora からウェブフックを送信する際、NGINX をリバースプロキシとして利用することを推奨しています。 > **注意** > > NGINX はフォワードプロキシサーバーを経由したリクエスト送信には対応していません。 > そのため、ウェブフックサーバーへのリクエストをフォワードプロキシサーバー経由で送信する場合は、NGINX 経由の送信は利用せず、sora.conf の webhook_proxy_url 設定を使用してください。 ### NGINX の設定例 Sora からのウェブフックサーバーへのアクセスに、NGINX を使用したリバースプロキシを使用する場合の設定例です。 この設定は `/etc/nginx/conf.d/webhook.conf` に保存することを想定しています。 `/etc/nginx/nginx.conf` の `http` ディレクティブに、 `include /etc/nginx/conf.d/*.conf;` がない場合や、 コメントアウトされていて `/etc/nginx/conf.d/webhook.conf` が読み込まれない場合は、 `include` ディレクティブを追加、または、コメントアウトを外して `/etc/nginx/conf.d/webhook.conf` が読み込まれるようにしてください。 Sora からのウェブフックサーバーへのリクエストを NGINX で HTTP で受信して、HTTPS でウェブフックサーバーに転送します Sora と NGINX 間の通信は HTTP のため、下記の設定例は Sora と同じサーバーに NGINX をインストールしてある前提です この設定を使用する場合は、 `nginx.conf` の `listen` ディレクティブのポート番号は、 `sora.conf` の `auth_webhook_url`, `event_webhook_url`, `session_webhook_url`, `stats_webhook_url` の設定と合わせてください。 ```nginx server { # 外からのリクエストは受信しない # ポート番号は sora.conf の auth_webhook_url, event_webhook_url, session_webhook_url, stats_webhook_url の設定と合わせてください listen 127.0.0.1:18080; # 名前解決に使用するリゾルバの設定 # 転送先ウェブフックサーバーへのリクエスト時にホスト名の名前解決が必要な場合は、 # resolver ディレクティブに、/etc/resolv.conf で利用している DNS サーバー、 # または、環境標準の DNS サーバーの IP アドレスを設定してください # また、resolver ディレクティブを使用しない場合には、location ディレクティブの proxy_pass への # 転送先 URI 指定には変数を使用しないでください resolver 127.0.0.53 valid=30s; access_log /var/log/nginx/upstream_access.log; error_log /var/log/nginx/upstream_error.log warn; # HTTP の HOST ヘッダーと TLS の SNI、proxy_pass での転送先指定で使用するホスト名の設定 # 転送先ウェブフックサーバーのホスト名を設定してください set $upstream_host "webhook.example.com"; proxy_http_version 1.1; proxy_set_header Host $upstream_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto http; # Basic 認証をパススルーする場合は下記のコメントアウトを外します # proxy_set_header Authorization $http_authorization; # プロキシタイムアウト設定 proxy_connect_timeout 5s; proxy_send_timeout 30s; proxy_read_timeout 30s; # リクエストサイズ制限 client_max_body_size 1m; # リトライ抑制：POST の二重送信を避ける proxy_next_upstream off; # レスポンスの Location 書き換えを無効化 proxy_redirect off; proxy_ssl_server_name on; proxy_ssl_name $upstream_host; proxy_ssl_verify on; # TLS の証明書検証で使用する CA 証明書の指定 # 下記以外に、自己発行証明書を使用する場合や他のパスに設置した CA 証明書を使用する場合は、 # その CA 証明書のパスを proxy_ssl_trusted_certificate ディレクティブに設定してください ## Ubuntu の場合 # proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt; ## RHEL の場合 # proxy_ssl_trusted_certificate /etc/pki/tls/certs/ca-bundle.crt; # Upstream TLS 証明書の検証時に許可する証明書チェーンの深さの指定 # # 利用者環境によっては異なる証明書チェーンが使用されるため、 # 以下のような証明書検証エラーが発生した場合は、 # 転送先の証明書チェーンおよび CA 設定を確認し、 # 必要に応じて proxy_ssl_verify_depth の値を調整を試みてください # # unable to get local issuer certificate # certificate verify error # proxy_ssl_verify_depth 3; # sora.conf の auth_webhook_url に設定した URI のパスと合わせてください location = /sora/webhook/auth { # POST 以外を拒否 limit_except POST { deny all; } # 認証ウェブフックの転送先 URI を指定してください proxy_pass https://$upstream_host:28080/sora/webhook/auth; } # sora.conf の event_webhook_url に設定した URI のパスと合わせてください location = /sora/webhook/event { # POST 以外を拒否 limit_except POST { deny all; } # イベントウェブフックの転送先 URI を指定してください proxy_pass https://$upstream_host:28080/sora/webhook/event; } # sora.conf の session_webhook_url に設定した URI のパスと合わせてください location = /sora/webhook/session { # POST 以外を拒否 limit_except POST { deny all; } # セッションウェブフックの転送先 URI を指定してください proxy_pass https://$upstream_host:28080/sora/webhook/session; } # sora.conf の stats_webhook_url に設定した URI のパスと合わせてください location = /sora/webhook/stats { # POST 以外を拒否 limit_except POST { deny all; } # 統計ウェブフックの転送先 URI を指定してください proxy_pass https://$upstream_host:28080/sora/webhook/stats; } # location で設定されていないパスは 404 location / { return 404; } } ``` ## カーネルパラメーターの適用 Sora は UDP を利用します。音声や映像の配信では大量の UDP を処理するため Linux のデフォルトの設定だと厳しい場合があります。 そのため、パラメーターの変更を推奨しています。 詳細は [Linux カーネルチューニング](LINUX_KERNEL_TUNING.html) をご確認ください。 ## コンテナ環境での利用する場合 ### 認識するコア数と利用できるコア数に矛盾がないかの確認 Sora をコンテナ環境で利用する場合、 コンテナが認識するコア数と実際にコンテナが利用できるなコア数が異なる環境があります。 Sora は **コンテナが認識するコア数を想定した挙動** をするため、 Sora の性能劣化が発生する場合があります。 コンテナが認識するコア数とコンテナが利用できるコア数が異なる場合は **必ずサポートまでご連絡ください** 。 コンテナが認識するコア数は以下のコマンドで確認できます。 ```bash $ grep processor /proc/cpuinfo | wc -l ``` - AWS ECS on EC2 利用時にコンテナが認識するコア数と利用できるコア数が異なることを確認しています ## SDK の利用 Sora へ接続する場合は、弊社がオープンソースとして公開している SDK を利用してください。 これらのライブラリは弊社によって最新版の Sora で動作するようにメンテナンスされています。 導入もとても簡単になっているので、是非利用してください。 > **重要** > > SDK に関する質問・要望・バグなどの報告は Discord の利用をお願いします。 > Sora のライセンス契約の有無に関わらず、 > 応答時間と問題の解決を保証しませんのでご了承ください。 > > ただし、明らかなバグについては優先的に対応しますので、ご安心ください。 SDK の質問や相談については `sora-sdk-faq` を利用してください。 - Sora JavaScript SDK- 投稿時に `sora-js-sdk` タグを指定してください - Sora iOS SDK- 投稿時に `sora-ios-sdk` タグを指定してください - Sora Android SDK- 投稿時に `sora-android-sdk` タグを指定してください - Sora Unity SDK- 投稿時に `sora-unity-sdk` タグを指定してください - Sora C++ SDK- 投稿時に `sora-cpp-sdk` タグを指定してください - Sora Python SDK- 投稿時に `sora-python-sdk` タグを指定してください - Sora Rust SDK- 投稿時に `sora-rust-sdk` タグを指定してください - Sora Flutter SDK- 投稿時に `sora-flutter-sdk` タグを指定してください ## やりたいことが 1:1 の双方向配信の場合 配信が 1:1 の双方向の場合はマルチストリーム機能を利用してください。 詳細は [マルチストリーム機能](MULTISTREAM.html) をご確認ください。 ## やりたいことが複数人での双方向配信の場合 複数人で双方向の配信を行いたい場合はスポットライト機能を検討してください。 スポットライト機能を利用することで、クライアントとサーバー側の負荷をかなり抑えられるようになります。 詳細は [スポットライト機能](SPOTLIGHT.html) をご確認ください。 ## やりたいことが 1:多 の双方向配信の場合 配信が 1:多 の片方向の場合でもマルチストリーム機能を利用してください。 `role` に `sendonly` と `recvonly` を利用してください。 詳細は [マルチストリーム機能](MULTISTREAM.html) をご確認ください。 ## やりたいことが 1:多 の片方向配信で、大規模の場合 配信が 1:多 の片方向で大規模な場合は、クラスターリレー機能を利用してください。 クラスターリレー機能を利用することで、1 チャネルで大規模な配信を行うことができます。 詳細は [リレー機能](CLUSTER.html#4b3bf1) をご確認ください。 ## やりたいことが OBS からの配信の場合 OBS からの配信を行いたい場合は OBS (WHIP) 対応機能を利用してください。 詳細は [WHIP 機能](WHIP.html) をご確認ください。 ## やりたいことが OBS での取り込みの場合 OBS へ取り込みを行いたい場合は OBS (WHEP) 対応機能を利用してください。 詳細は [WHEP 機能](WHEP.html) をご確認ください。 ## Edge が機能要件に含まれている場合 最新の Edge であれば、ほとんど Chrome と同じ動きをしますので安心してお使いください。 ## Firefox が機能要件に含まれている場合 Firefox の WebRTC 実装はかなり中途半端なため、 できるだけ Firefox は機能要件から外すことをお勧めします。 ## 認証を外部の指定した HTTP サーバーで判断したい場合 認証ウェブフック機能を利用してください。この機能は外部の指定した HTTP サーバーで認証を判断できるようになります。 外部の HTTP サーバーの URL 指定は `sora.conf` の [auth_webhook_url](SORA_CONF.html#36a99a) に設定してください。 そうすることで、外部に認証を移譲できます。 詳細は [認証ウェブフック](AUTH_WEBHOOK.html) をご確認ください。 ## 接続、切断の検知を外部の指定した HTTP サーバーで利用したい場合 イベントウェブフック機能を利用してください。この機能は外部の指定した HTTP サーバーでクライアント単位での接続、切断を検知できるようになります。 外部の HTTP サーバーの URL 指定は `sora.conf` の [event_webhook_url](SORA_CONF.html#e1a4d2) に設定してください。 そうすることで、外部にイベントをリクエスト送信できます。 詳細は [イベントウェブフック](EVENT_WEBHOOK.html) をご確認ください。 ## 配信されている音声や映像を記録したい場合 Sora には録画機能があります。もし利用を検討されている場合はいくつか注意事項があります。 - 録画を終了させる、またはクライアントが切断するまで、録画ファイルは生成されない - 複数人数が参加する会議の録画ファイルはクライアントごとに生成される- 5 人が会議に参加していれば 5 個ファイルが生成されます これらを踏まえて録画機能の利用を検討してください。 録画機能の詳細は [録画機能](RECORDING.html) をご確認ください。 ## クライアント側で参加してきたユーザーの情報を通知したい場合 Sora では「〜さんが会議に参加しました」や「〜さんが会議から退席しました」というメッセージをクライアント側で流すことができます。 これにはシグナリング通知を利用します。 シグナリング通知機能はシグナリングで利用している WebSocket もしくは DataChannel を経由して、 参加しているチャネルに新しく参加、または退席した状態を通知する機能です。自分が参加したときも自身に参加通知は飛びます。 ただシグナリング通知に含まれる標準の情報はあくまでコネクション ID のみになるため、 そのコネクション ID が誰なのかはどこからか取得する必要があります。 そのコネクション ID が誰なのかを問い合わせる処理が毎回走ってしまうのは無駄なため、 認証ウェブフックの戻り値で、 `signaling_notify_metadata` （シグナリング通知メタデータ）にそのコネクション ID の値のユーザー名を含めてください。 そうすることで、Sora がその参加者のユーザー名を `signaling_notify_metadata` に含めて返すようになります。 この `signaling_notify_metadata` は新しく参加した人には `data` として、 既存の参加している人の `signaling_notify_metadata` が含まれたリストが参加時に通知されるようになっています。 さらに、新しく参加者がいた場合はその参加者の `metadata` が通知されます。もちろん退席者の場合でもその退席者の `metadata` が含まれて通知されます。 `metadata` にユーザー名が含まれるため、サーバーへ問い合わせをしなくても参加者や退席者のユーザー名を取得できます。 シグナリング通知の詳細は [シグナリング通知](SIGNALING_NOTIFY.html) をご確認ください。 シグナリング通知メタデータの詳細は [シグナリング通知メタデータ](SIGNALING_NOTIFY_METADATA.html) をご確認ください。