以下のドキュメントは、カスタム手動審査の統合方式についての説明です。審査タスクの開始と終了をご自身で管理する必要があります。
審査フローへのアクセス
フローチャートへのアクセス
統合の手順
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 | はい | | このフィールドで表示するのは、入力するオーディオ審査タスク情報です。具体的な入力内容については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とはなにか。
6. TRTCではどうやって生成したuser_sigが正しいか検証しているのですか。ルーム参加のエラーメッセージ-3319、-3320のエラーはどのように調査したらいいですか。
7. 多人数がボイスチャットルームにいると、マルチストリームになります。どのように不正を判断しますか。
現在は、返されたコールバック上のアドレスによる区別のみです。コールバックのセグメントはCOSにストレージされます。ファイル名はtrtc_[room_id]_[user_id]_timestampという形式です。
8. 結合したTRTC審査URLについて、どのような注意点がありますか。
user_sigには特殊記号が含まれていますので、結合してurlとする前に、escapeを実行してからURLに含める必要があります。
付録
オーディオ審査サービス以下の4つの審査インターフェースを提供します。リンクをクリックすると、インターフェースについての詳細なドキュメントを表示します。
ビデオ審査サービス以下の4つの審査インターフェースを提供します。リンクをクリックすると、インターフェースについての詳細なドキュメントを表示します。