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

Memecahkan masalah yang berhubungan 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, peer pengendali memulai koneksi ke peer yang dikontrol dengan mengirimkan penawaran SDP. Untuk peer-to-peer sesi, peserta pemirsa memulai koneksi dengan mengirimkan penawaran kepada peserta utama melalui Signaling. Saat menghubungkan ke sesi penyimpanan untuk konsumsi WebRTC, sesi penyimpanan adalah rekan pengendali. Untuk peserta master, mereka masih tetap menjadi peserta yang terkontrol. Namun, peserta pemirsa beralih dari kontrol ke kontrol.

Setelah menelepon JoinStorageSessionatau JoinStorageSessionAsViewer, semua peserta harus menanggapi 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. correlationIdMenyertakan a dalam pesan memungkinkan sesi penyimpanan untuk mengembalikan statusResponse pesan. Pesan-pesan ini akan berisi pesan masukan, memungkinkan Anda untuk melacak pesan mana yang statusResponse dimiliki. correlationId Ini memungkinkan Anda 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 karena sesi penyimpanan tidak dapat menerima codec yang ditentukan dalam jawabannya. Sampel statusResponse mungkin terlihat seperti berikut:

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

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

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

Lihat JoinStorageSessiondaftar 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 ada:

Untuk peserta pemirsa, persyaratan berikut diberlakukan:

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

Saat menggunakan aplikasi sampel konsumsi WebRTC yang disediakan KVS:

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. senderClientId

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

Tinjau logika antrian kandidat ICE

Semua kandidat ICE yang diterima dari sesi penyimpanan perlu ditambahkan ke RTCPeer Koneksi melalui addIceCandidate API.

Meskipun sesi penyimpanan mengirimkan penawaran SDP sebelum kandidat ICE, karena sifat tidak sinkron dari pengiriman pesan Signaling, aplikasi dapat menerima kandidat ICE sebelum menerima penawaran.

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

Logika yang diterapkan dalam aplikasi sampel KVS adalah sebagai berikut: