tencent cloud

以下のドキュメントは、カスタム手動審査の統合方式についての説明です。審査タスクの開始と終了をご自身で管理する必要があります。

審査フローへのアクセス

フローチャートへのアクセス

統合の手順

1. ユーザーは、TRTCが提供するSDKでルームを作成し、TRTCを開始後に、sdk_app_id（TRTCコンソールでアプリケーションを作成する際のアプリケーションID）、room_id（作成したルームナンバー）を取得できます。TRTC SDKで、そのルームのコンテンツ審査ユーザー（ルーム1室あたり異なるコンテンツ審査user_idの作成を推奨）を作成すると、user_idおよびuser_sigを取得できます（コンテンツセキュリティは、そのユーザーが視聴者として入室したルームでプルしたCSSストリームのデータを使用）。
2. 前のステップで獲得したsdk_app_id、room_id、user_idおよびuser_sigを結合してTRTC審査URLを作成します。URL形式は以下のとおりです。

   trtc://trtc.tencentcloudapi.com/moderation?sdk_app_id=xxxx&room_id=xxxx&user_id=xxxx&user_sig=xxxx
   

注意：

• URLの各パラメータ値を結合する前に、escapeする必要があります。特殊文字、特にuser_sigにより、解析できなくなることを防ぎます。
• このドキュメントが関連するTRTCパラメータであるsdk_app_id、user_id、user_sig、room_id、アクセスするTRTC SDKのSdkAppId、UserId、UserSig、RoomIdにそれぞれ対応します。

パラメータ名	入力必須	説明
sdk_app_id	はい	TRTCコンソールでアプリケーションを作成したときのアプリケーションIDです。
room_id	はい	作成したルームナンバーです。TRTCのroom_idには数字および文字列の2つの形式があります。デフォルトは数字です。文字列のroom_idの場合は、room_id_typeをstringに設定する必要があります。
user_id	はい	ユーザーIDです。各ルームで異なるコンテンツ審査user_idを作成することを推奨します。
user_sig	はい	user_sigは、sdk_app_idとuser_idに基づき計算されたセキュリティ署名です。
mix	いいえ	trueは、ミクスストリーミング審査、falseはシングルストリーミングで値を取得します。 入力不要なデフォルトは、ミクスストリーミング審査です。 （ミクスストリーミング審査において、不正なコールバックでは具体的な不正ユーザーを特定できません。ルーム次元でのコンプライアンス審査シーンに適しています。シングルストリーミング審査では、コールバックにより具体的な不正user_idを特定可能です。）
room_id_type	いいえ	ルームタイプです。デフォルトでは渡せません。渡すことができる値はstring/numberです。

3. 審査タスクの作成 インターフェースにより、このルームのコンテンツセキュリティ審査を開始します。

   パラメータ名	入力必須	タイプ	説明
   Action	はい	String	パブリック共通パラメータです。このインターフェースの値はCreateAudioModerationTaskです。
   Version	はい	String	パブリック共通パラメータです。このインターフェースの値は2020-12-29です。
   Region	いいえ	String	パブリック共通パラメータです。対応する海外リージョンを指定します。現在はシンガポール(ap-singapore)のみをサポートしています。
   Tasks.N	はい	Array of TaskInput	このフィールドで表示するのは、入力するオーディオ審査タスク情報です。具体的な入力内容についてはTaskInputデータ構造の詳細説明をご参照ください。 備考：最大10個のタスクを同時に作成できます。
   BizType	いいえ	String	このフィールドで表示するのは、インターフェースのスケジューリングに使用するポリシーの具体的な番号です。MSコンソ－ルで設定できます。Biztypeパラメータを渡さない（ブランクをあける）場合は、デフォルトの認識ポリシーを採用したことになります。渡した場合は、審査時に業務シナリオに応じて異なる審査ポリシーを採用します。 備考：Biztypeは、 数字、アルファベット、アンダーバーの組み合わせのみで、長さは3～32文字です。Biztype別に関連する業務シーンと認識ポリシーが異なります。呼び出し前に、正しいBiztypeかどうかを確認してください。
   Type	いいえ	String	このフィールドで表示するのは、入力するオーディオ審査のタイプです。取得する値はAUDIO（オンデマンドオーディオ）およびLIVE_AUDIO（ライブストリーミングオーディオ）で、デフォルト値はAUDIOです。
   Seed	いいえ	String	パラメータは選択可能です。このフィールドで表示するのは、データのセキュリティを保証するのに用いるコールバック署名のkey情報です。署名方法は、戻されたHTTPヘッダーにX-Signatureのフィールドを追加します。値はseed + bodyのSHA256コードおよびHex文字列です。コールバックデータを受信後、返されたbodyに基づき、sha256(seed + body)を用いてX-Signatureを算出し、検証を実行することができます。具体的な使用インスタンスについてはコールバック署名の例をご参照ください。
   CallbackUrl	いいえ	String	パラメータは選択可能です。このフィールドで表示するのは、審査情報のコールバックを受信するアドレスです。デフォルトの形式はURLリンクです。設定完了後、審査中に発生した不正オーディオセグメントをこのインターフェースから送信します。コールバックリターンコンテンツの形式についてはコールバック署名の例をご参照ください。

上記は、オーディオ審査タスク作成インターフェースについての事例です。ビデオ審査タスクを開始する場合は、ビデオ審査タスクを呼び出してインターフェースを作成してください。
このインターフェースでは、次のいくつかの点に注意してください。

• BizType
  ユーザーの審査ポリシーは、コンソール上のポリシー管理 により、ニーズに応じてさまざまな審査ポリシーを作成できます。サービスアクティブ時に、自動でBizType が「default」の審査ポリシーを作成します。テスト時には、そのBizTypeを用いて渡すことができます。
  
• Type
  実際のアプリケーションタイプに基づいて渡します。TRTCは、アプリケーションタイプに基づいて、さまざまな製品のインターフェースを呼び出します。（例：リアルタイム音声シーンでは、ams製品のインターフェースを呼び出し、TypeにLIVE_AUDIOを入力します。ビデオチャットでは、vm製品のインターフェースを呼び出し、TypeにLIVE_VIDEOを入力します）。
• CallbackUrl
  このアドレスは、ユーザーインターフェースのライブストリーミング中、およびライブストリーミング終了の審査結果に用います。コンソールの設定インターフェースで設定でき、インターフェースから渡すことも可能です。コールバック形式はタスクの詳細インターフェースを確認の出力パラメータと同じです。
• Tasks.N.Input.Url
  ステップ2で結合したTRTC審査URLを入力します。入力実例：
  

4. 審査タスクの作成に成功しました。Tencent Cloudコンテンツセキュリティ審査サービスは、そのルーム審査に対する唯一のIDとしてTaskIdを返します。
5. 審査中、ユーザーのコールバックサーバーは、継続してコンテンツセキュリティ審査サービスの審査結果を受信します。TRTCについては、ライブストリーミング中の、各ユーザーのオーディオを分割したものおよび画像キャプチャの審査結果です。ユーザーは結果に基づき、ライブストリーミングルームをロックするかどうかを決定できます。もしくは、ライブストリーミングルームに警告を送信することができます。
6. ライブストリーミング終了後、ユーザーは審査インターフェースを呼び出し（審査作成時のTaskIdを渡し）、ライブストリーミングルームの審査を終了します。
7. コンテンツセキュリティ審査サービスは審査終了のリクエストを受信すると、ライブストリーミングルームのデータストリームのプルを停止し、審査ポリシーに基づき、ライブストリーミングルームの最終審査結果をエクスポートします。同時に、審査終了のコールバック情報をユーザーに送信します。TRTCコールバックはcosにストレージされます。ファイル名：

   trtc/{{sdk_app_id}}/screenshot_{{room_id}}_{{user_id}}{{timestamp}}.jpg（画像形式）
   trtc/{{sdk_app_id}}/audio{{room_id}}_{{user_id}}_{{timestamp}}.mp3（オーディオ形式）
   
   

注意：

• ミクスストリーミングのuser_idはmixerに統一されています。
• ライブストリーミングコンテンツセキュリティ審査中に、CSSストリームが中断、または継続的にデータストリームがプルできない場合は、プルを再試行します。しばらくの間（エラーコードによって再試行のロジックは異なります）データストリームがプルできないため、ライブストリーミングルームがすでに閉じられたと認識し、審査結果のコールバックをユーザーに送信します。そのため、ユーザーは、コールバック受信後に、ライブストリーミングルームが閉じられているかどうかを判断する必要があります。閉じられていない場合は、審査を再度開始することで、ライブストリーミングルームに漏れを起こさないよう保証します）

よくあるご質問

1. TRTCがコンテンツセキュリティ審査する際に渡したuser_idは、ユーザーから見えますか。

見えません。コンテンツセキュリティは視聴者審査をTRTCからプルしていますので、ユーザー側からuser_idは見えません。

2. コンテンツセキュリティがTRTCからプルするデータストリームは課金されますか。

コンテンツセキュリティ審査は、視聴者IDでTRTCからデータストリームをプルし、審査を行います。TRTCのデフォルト課金方式は、サブスクリプション時間（プル）に応じた課金ですので、ここでは料金が発生します。具体的な料金についてはオーディオビデオ課金時間の説明をご参照ください。

注意：

• 審査タスクuser_idの作成において、同じルーム内ではいかなるものであっても、同じuser_idは存在できません。
• TRTC room_idの制限はuintです。ルームナンバーの値の範囲は、1～4294967295です。開発者が自主的にメンテナンスとアサインを行います。

3. コンテンツセキュリティは、視聴者審査でTRTCからプルしますが、このコンテンツ審査ユーザーは、正常に作成されたユーザーでしょうか。

正常なユーザーです。ユーザー入室時のプルデータを用いていますので、このユーザーも正常なユーザーです。

4. TRTCのオーディオ、ビデオに対してコンテンツ審査を行い、審査結果が返るまでに、それぞれどのくらい時間がかかりますか。

セグメントはリアルタイムで返ります。オーディオのリアルタイム率は0.2、画像はデータ取得後1s以内に返ります。

5. user_sigとはなにか。

より詳細な説明をご覧になる場合は、user_sig関連をご参照ください。

6. TRTCではどうやって生成したuser_sigが正しいか検証しているのですか。ルーム参加のエラーメッセージ-3319、-3320のエラーはどのように調査したらいいですか。

TRTCコンソールにログインし、開発支援 > **user_sig生成&検証**を選択すれば、user_sigを検証できます。

7. 多人数がボイスチャットルームにいると、マルチストリームになります。どのように不正を判断しますか。

現在は、返されたコールバック上のアドレスによる区別のみです。コールバックのセグメントはCOSにストレージされます。ファイル名はtrtc_[room_id]_[user_id]_timestampという形式です。

8. 結合したTRTC審査URLについて、どのような注意点がありますか。

user_sigには特殊記号が含まれていますので、結合してurlとする前に、escapeを実行してからURLに含める必要があります。

説明：

その他のご質問については、 TRTCについてのよくあるご質問ドキュメントをご参照ください。

付録

• オーディオ審査サービス以下の4つの審査インターフェースを提供します。リンクをクリックすると、インターフェースについての詳細なドキュメントを表示します。
  • 審査タスクの作成
  • 審査の終了
  • 審査タスクリストの照会
  • 審査タスクの詳細についての照会
• ビデオ審査サービス以下の4つの審査インターフェースを提供します。リンクをクリックすると、インターフェースについての詳細なドキュメントを表示します。
  • 審査タスクの作成
  • 審査の終了
  • 審査タスクリストの照会
  • 審査タスクの詳細についての照会