Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memecahkan masalah yang terhubung dengan sesi penyimpanan

Bagian ini memberikan panduan tentang masalah pemecahan masalah yang terkait dengan pengaturan dan konfigurasi penyimpanan untuk merekam aliran video.

Mengontrol dan mengendalikan rekan-rekan

Di WebRTC, rekan pengontrol memulai koneksi ke peer yang dikendalikan dengan mengirimkan penawaran SDP. Untuk sesi peer-to-peer, peserta pemirsa memulai koneksi dengan mengirimkan penawaran ke peserta master melalui Pensinyalan. Saat menghubungkan ke sesi penyimpanan untuk penyerapan WebRTC, sesi penyimpanan adalah rekan pengontrol. Untuk peserta master, mereka masih tetap menjadi peserta yang dikendalikan. Namun, peserta pemirsa beralih dari mengendalikan ke terkontrol.

Setelah menelepon JoinStorageSession atau JoinStorageSessionAsViewer, semua peserta harus merespons dengan jawaban SDP dan bertukar kandidat ICE dengan sesi penyimpanan.

Untuk diagram urutan, lihat Memahami konsumsi dan penyimpanan WebRTC.

Tinjau codec yang didukung

Saat mengirim jawaban SDP dan bertukar kandidat ICE dengan sesi penyimpanan, kami sarankan untuk menyertakan a correlationId dalam pesan. Memasukkan a correlationId dalam pesan memungkinkan sesi penyimpanan untuk mengembalikan statusResponse pesan. Pesan-pesan ini akan berisi pesan input, memungkinkan Anda untuk melacak pesan mana yang statusResponse dimiliki. correlationId Ini memungkinkan Anda untuk menerima umpan balik langsung tentang mengapa jawaban SDP Anda ditolak.

Untuk informasi selengkapnya tentang correlationId dan statusResponse, lihat Penerimaan pesan asinkron.

Salah satu alasan umum sesi penyimpanan mungkin menolak jawaban SDP adalah bahwa sesi penyimpanan tidak dapat menerima codec yang ditentukan dalam jawaban. Sampel statusResponse mungkin terlihat seperti berikut:

{
  "correlationId": "1700186220273",
  "errorType": "InvalidArgumentException",
  "statusCode": "400",
  "success": false
}

Saat Anda meninjau konten jawaban SDP, tinjau baris yang dimulai dengan a=rtpmap dan verifikasi bahwa codec cocok dengan codec yang didukung sesi penyimpanan. Di bawah ini adalah cuplikan contoh jawaban SDP yang berisi audio opus dan video VP8.

...
a=rtpmap:111 opus/48000/2
...
a=rtpmap:120 VP8/90000
...

Lihat JoinStorageSession untuk daftar codec yang didukung.

Jika saluran tidak dipetakan ke aliran, juga akan membuang 400 InvalidArgumentException

Tinjau arah transceiver

Dalam jawaban SDP, tinjau arah transceiver video dan audio. Garis-garis di SDP terlihat seperti ini:

a=sendrecv
a=recvonly

Untuk peserta master, persyaratan berikut berlaku:

Untuk peserta pemirsa, persyaratan berikut berlaku:

Jika persyaratan layanan tidak terpenuhi, StatusResponse dengan 400 IllegalArgumentException akan dikembalikan jika CorrelationId diberikan saat jawaban dikirim.

Saat menggunakan aplikasi sampel konsumsi KVS-provided WebRTC:

Tinjau konversi kandidat ICE

Saat menerima kandidat ICE dari KVS Signaling SDK, aplikasi mungkin perlu mengubah string menjadi objek kandidat ICE.

Kandidat ICE yang diterima dari sesi penyimpanan tidak mengandung properti SDPMID, dan tidak datang dengan pengirim. ClientId

Tinjau logika aplikasi Anda untuk menambahkan kandidat ICE yang diterima dari jarak jauh ke RTCPeerConnection objek aplikasi Anda.

Tinjau logika antrian kandidat ICE

Semua kandidat ICE yang diterima dari sesi penyimpanan perlu ditambahkan ke RTCPeerConnection via add IceCandidate API.

Meskipun sesi penyimpanan mengirimkan penawaran SDP sebelum kandidat ICE, karena sifat asinkron dari pengiriman pesan Sinyal, aplikasi dapat menerima kandidat ICE sebelum menerima penawaran.

Dalam hal ini, Anda perlu menerapkan buffer sementara untuk menahan kandidat ICE.

Logika yang diimplementasikan dalam aplikasi sampel KVS adalah sebagai berikut: