Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memecahkan Masalah Amazon Kinesis Video Streams dengan WebRTC
Gunakan informasi berikut untuk memecahkan masalah umum yang mungkin Anda temui dengan Amazon Kinesis Video Streams dengan WebRTC.
## Masalah membangun peer-to-peer sesi
WebRTC dapat membantu meringankan masalah yang terjadi karena:
+ Terjemahan alamat jaringan (NAT)
+ firewall
+ Proksi antar rekan
WebRTC menyediakan kerangka kerja untuk membantu bernegosiasi dan memelihara koneksi selama rekan-rekan terhubung. Ini juga menyediakan mekanisme untuk menyampaikan media melalui `TURN` server jika peer-to-peer koneksi tidak dapat dinegosiasikan.
Mengingat semua komponen yang diperlukan untuk membangun koneksi, ada baiknya memahami beberapa alat yang tersedia untuk membantu memecahkan masalah yang terkait dengan membuat sesi.
**Topics**
+ [Penawaran dan jawaban Session Description Protocol (SDP)](#sdp)
+ [Evaluasi generasi kandidat ICE](#ice-candidate)
+ [Tentukan kandidat mana yang digunakan untuk membangun koneksi](#determine-candidate)
+ [Batas waktu terkait ICE](#troubleshooting-ice-timeouts)
### Penawaran dan jawaban Session Description Protocol (SDP)
Session Description Protocol (SDP) menawarkan dan menjawab menginisialisasi sesi RTC antara rekan-rekan.
Untuk mempelajari lebih lanjut tentang protokol SDP, lihat [spesifikasinya](https://www.rfc-editor.org/rfc/rfc4566#section-5).
+ **Penawaran** dihasilkan oleh “pemirsa” yang ingin terhubung ke rekan yang terhubung ke saluran pensinyalan sebagai “master” di Kinesis Video Streams dengan WebRTC.
+ **Jawaban** dihasilkan oleh penerima penawaran.
Baik penawaran dan jawaban dihasilkan di sisi klien, meskipun mereka mungkin berisi kandidat ICE yang telah dikumpulkan hingga saat itu.
[Kinesis Video Streams SDK WebRTC untuk C menyertakan variabel lingkungan sederhana yang dapat Anda atur untuk mencatat SDP](https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c#getting-the-sdps). Ini berguna untuk memahami penawaran yang diterima dan jawaban yang dihasilkan.
SDPs Untuk masuk `stdout` dari SDK, setel variabel lingkungan berikut:`export DEBUG_LOG_SDP=TRUE`. Anda juga dapat mencatat penawaran dan jawaban SDP di klien JavaScript berbasis menggunakan `sdpOffer` acara tersebut. Untuk melihat ini ditunjukkan, lihat [GitHub](https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-js/blob/983b62f07330e05277fd072f8062fecd8233bce7/examples/master.js#L123).
Untuk informasi tambahan, lihat [Pantau Kinesis Video Streams dengan WebRTC](kvswebrtc-monitoring-cw.md).
Jika jawaban SDP tidak dikembalikan, ada kemungkinan rekan tidak dapat menerima penawaran SDP, karena penawaran tersebut tidak mengandung codec media yang kompatibel. Anda mungkin melihat log yang mirip dengan berikut ini:
```
I/webrtc_video_engine.cc: (line 808): SetSendParameters: {codecs: [VideoCodec[126:H264]], conference_mode: no, extensions: [], extmap-allow-mixed: false, max_bandwidth_bps: -1, mid: video1}
E/webrtc_video_engine.cc: (line 745): No video codecs supported.
E/peer_connection.cc: (line 6009): Failed to set remote video description send parameters for m-section with mid='video1'. (INVALID_PARAMETER)
E/peer_connection.cc: (line 3097): Failed to set remote offer sdp: Failed to set remote video description send parameters for m-section with mid='video1'.
E/KinesisVideoSdpObserver: onSetFailure(): Error=Failed to set remote offer sdp: Failed to set remote video description send parameters for m-section with mid='video1'.
D/KVSWebRtcActivity: Received SDP offer for client ID: null. Creating answer
E/peer_connection.cc: (line 2373): CreateAnswer: Session error code: ERROR_CONTENT. Session error description: Failed to set remote video description send parameters for m-section with mid='video1'..
E/KinesisVideoSdpObserver: onCreateFailure(): Error=Session error code: ERROR_CONTENT. Session error description: Failed to set remote video description send parameters for m-section with mid='video1'..
```
Saat Anda meninjau konten penawaran SDP, cari baris yang dimulai `a=rtpmap` untuk melihat codec media mana yang diminta.
```
...
a=rtpmap:126 H264/90000
...
a=rtpmap:111 opus/48000/2
...
```
**Jika Anda menggunakan Safari sebagai penampil untuk terhubung ke master yang mengirim media H.265 dan Anda menemukan yang berikut:**
+ `InvalidAccessError: Failed to set remote answer sdp: Called with SDP without DTLS fingerprint.`
+ `InvalidAccessError: Failed to set remote answer sdp: rtcp-mux must be enabled when BUNDLE is enabled.`
Konfirmasikan masalahnya adalah dengan penawaran SDP yang dihasilkan oleh browser. Dalam penawaran SDP, cari baris mulai`a=rtpmap`, dan periksa apakah ada garis untuk H.265. Seharusnya terlihat seperti ini:
```
a=rtpmap:104 H265/90000
```
Jika tidak ada, aktifkan codec H.265 untuk WebRTC di pengaturan Safari.
Di navigasi atas Safari, lakukan hal berikut:
+ Pilih **Safari** > **Pengaturan...** > **Lanjutan**. Pilih kotak **Tampilkan fitur untuk pengembang web**.
+ Pilih **Bendera Fitur**. Pilih kotak codec **WebRTC H265**.
Mulai ulang browser Anda agar perubahan diterapkan.
### Evaluasi generasi kandidat ICE
Kandidat ICE dihasilkan oleh setiap klien yang melakukan panggilan ke `STUN` server. Untuk Kinesis Video Streams dengan WebRTC`STUN`, server adalah. `stun:stun.kinesisvideo.{aws-region}.amazonaws.com:443`
Selain memanggil `STUN` server untuk mendapatkan kandidat, klien sering juga memanggil `TURN` server. Mereka melakukan panggilan ini sehingga server relay dapat digunakan sebagai fallback jika peer-to-peer koneksi langsung tidak dapat dibuat.
Anda dapat menggunakan alat-alat berikut untuk menghasilkan kandidat ICE:
+ [Sampel WebRTC Trickle ICE, yang menggunakan Trickle ICE untuk mengumpulkan](https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/) kandidat
+ [IceTest.Info](https://icetest.info/)
Dengan kedua alat ini. Anda dapat memasukkan informasi `STUN` dan `TURN` server untuk mengumpulkan kandidat.
[Untuk mendapatkan informasi `TURN` server dan kredensi yang diperlukan untuk Kinesis Video Streams dengan WebRTC, Anda dapat memanggil operasi API. GetIceServerConfig ](https://docs.aws.amazon.com//kinesisvideostreams/latest/dg/API_AWSAcuitySignalingService_GetIceServerConfig.html)
AWS CLI Panggilan berikut menunjukkan cara mendapatkan informasi ini untuk digunakan dalam dua alat ini.
```
export CHANNEL_ARN="YOUR_CHANNEL_ARN"
aws kinesisvideo get-signaling-channel-endpoint \
--channel-arn $CHANNEL_ARN \
--single-master-channel-endpoint-configuration Protocols=WSS,HTTPS,Role=MASTER
```
Output dari [https://docs.aws.amazon.com//kinesisvideostreams/latest/dg/API_GetSignalingChannelEndpoint.html](https://docs.aws.amazon.com//kinesisvideostreams/latest/dg/API_GetSignalingChannelEndpoint.html)perintah mengembalikan respons yang terlihat seperti ini:
```
{
"ResourceEndpointList": [
{
"Protocol": "HTTPS",
"ResourceEndpoint": "https://your-endpoint.kinesisvideo.us-east-1.amazonaws.com"
},
{
"Protocol": "WSS",
"ResourceEndpoint": "wss://your-endpoint.kinesisvideo.us-east-1.amazonaws.com"
}
]
}
```
Gunakan `ResourceEndpoint` nilai HTTPS untuk mendapatkan daftar `TURN` server sebagai berikut:
```
export ENDPOINT_URL="https://your-endpoint.kinesisvideo.us-east-1.amazonaws.com"
aws kinesis-video-signaling get-ice-server-config \
--channel-arn $CHANNEL_ARN \
--service TURN \
--client-id my-amazing-client \
--endpoint-url $ENDPOINT_URL
```
Respons berisi rincian `TURN` server, termasuk titik akhir untuk TCP dan UDP dan kredensional yang diperlukan untuk mengaksesnya.
**catatan**
Nilai TTL dalam respons menentukan durasi, dalam hitungan detik, yang valid untuk kredensil ini. Gunakan nilai ini dalam [sampel WebRTC Trickle ICE atau [IceTestdi.Info](https://icetest.info/) untuk menghasilkan kandidat ICE](https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/) menggunakan titik akhir layanan yang dikelola Kinesis Video Streams.
### Tentukan kandidat mana yang digunakan untuk membangun koneksi
Akan sangat membantu untuk memahami kandidat mana yang digunakan untuk berhasil mendirikan sesi. Jika Anda memiliki klien berbasis browser yang menjalankan sesi yang telah ditetapkan, Anda dapat menentukan informasi ini di Google Chrome dengan menggunakan utilitas internal webrtc bawaan.
Buka sesi WebRTC di satu tab browser.
Di tab lain, buka`chrome://webrtc-internals/`. Anda dapat melihat semua informasi tentang sesi Anda yang sedang berlangsung di tab ini.
Anda akan melihat informasi tentang koneksi yang dibuat. Contoh:
Anda juga dapat mengonfirmasi metrik seperti berikut untuk koneksi yang dibuat.
### Batas waktu terkait ICE
Nilai batas waktu default ditetapkan untuk ICE di file. [KvsRtcConfiguration](https://awslabs.github.io/amazon-kinesis-video-streams-webrtc-sdk-c/structKvsRtcConfiguration.html) Default harus cukup untuk sebagian besar pengguna, tetapi Anda mungkin perlu menyesuaikannya untuk meningkatkan peluang membangun koneksi melalui jaringan yang buruk. Anda dapat mengonfigurasi default ini dalam aplikasi.
Tinjau log untuk pengaturan default:
```
2024-01-08 19:43:44.433 INFO iceAgentValidateKvsRtcConfig():
iceLocalCandidateGatheringTimeout: {{10000}} ms
iceConnectionCheckTimeout: {{12000}} ms
iceCandidateNominationTimeout: {{12000}} ms
iceConnectionCheckPollingInterval: {{50}} ms
```
Jika Anda memiliki kualitas jaringan yang buruk dan ingin meningkatkan peluang koneksi, coba sesuaikan nilai-nilai berikut:
+ `iceLocalCandidateGatheringTimeout`- Tingkatkan batas waktu tunggu ini untuk mengumpulkan kandidat potensial tambahan untuk mencoba koneksi. Tujuannya adalah untuk mencoba semua pasangan kandidat yang mungkin, jadi jika Anda berada di jaringan yang buruk, tingkatkan batas ini untuk memberi lebih banyak waktu untuk berkumpul.
Misalnya, jika kandidat host tidak bekerja dan server refleksif (srflx) atau kandidat relay perlu dicoba, Anda mungkin perlu menambah batas waktu ini. Karena jaringan yang buruk, para kandidat dikumpulkan perlahan dan aplikasi tidak ingin menghabiskan lebih dari 20 detik pada langkah ini. Meningkatkan batas waktu memberikan lebih banyak waktu untuk mengumpulkan kandidat potensial untuk mencoba koneksi.
**catatan**
Kami merekomendasikan bahwa nilai ini kurang dari`iceCandidateNominationTimeout`, karena langkah nominasi perlu memiliki waktu untuk bekerja dengan kandidat baru.
+ `iceConnectionCheckTimeout`- Tingkatkan batas waktu ini di jaringan yang tidak stabil atau lambat, di mana pertukaran paket dan permintaan/respons yang mengikat membutuhkan waktu. Peningkatan batas waktu ini memungkinkan setidaknya satu pasangan kandidat untuk diadili untuk dinominasikan oleh rekan lainnya.
+ `iceCandidateNominationTimeout`- Tingkatkan batas waktu ini untuk memastikan pasangan calon dengan kandidat estafet lokal dicoba.
Misalnya, jika dibutuhkan sekitar 15 detik untuk mengumpulkan kandidat estafet lokal pertama, atur batas waktu ke nilai lebih dari 15 detik untuk memastikan pasangan kandidat dengan kandidat estafet lokal dicoba untuk berhasil. Jika nilainya disetel ke kurang dari 15 detik, SDK akan kalah dalam mencoba pasangan kandidat potensial, yang menyebabkan kegagalan pembentukan koneksi.
**catatan**
Kami merekomendasikan bahwa nilai ini lebih besar dari`iceLocalCandidateGatheringTimeout`, agar memiliki efek.
+ `iceConnectionCheckPollingInterval`[- Nilai ini default hingga 50 milidetik per spesifikasi.](https://datatracker.ietf.org/doc/html/rfc8445#section-14.2) Mengubah nilai ini mengubah frekuensi pemeriksaan konektivitas dan, pada dasarnya, transisi mesin status ICE.
Dalam pengaturan jaringan kinerja tinggi yang andal dengan sumber daya sistem yang baik, Anda dapat mengurangi nilai untuk membantu dalam pembentukan koneksi yang lebih cepat. Meningkatkan nilai dapat membantu mengurangi beban jaringan, tetapi pembentukan koneksi bisa melambat.
**penting**
Kami tidak menyarankan untuk mengubah default ini.