Memahami konsep Media API
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Google Meet Media API memungkinkan aplikasi Anda bergabung ke
konferensi Google Meet dan menggunakan streaming media real-time.
Klien menggunakan WebRTC untuk berkomunikasi dengan server Meet. Klien referensi yang disediakan (C++,
TypeScript) menunjukkan praktik yang direkomendasikan dan
Anda dianjurkan untuk membuat aplikasi langsung berdasarkan klien tersebut.
Namun, Anda juga dapat membuat klien WebRTC yang sepenuhnya kustom dan mematuhi
persyaratan teknis
Meet Media API.
Halaman ini menguraikan konsep WebRTC utama yang diperlukan untuk sesi Meet Media API yang berhasil.
Sinyal penawaran-jawaban
WebRTC adalah framework peer-to-peer (P2P), tempat peer berkomunikasi dengan saling memberi sinyal. Untuk memulai sesi, peer yang memulai mengirimkan penawaran
SDP ke peer jarak jauh. Penawaran ini mencakup detail penting berikut:
Deskripsi media untuk audio dan video
Deskripsi media menunjukkan apa yang dikomunikasikan selama sesi P2P. Ada tiga jenis deskripsi: audio, video, dan data.
Untuk menunjukkan n streaming audio, penawar menyertakan n deskripsi media audio dalam penawaran. Hal yang sama berlaku untuk video. Namun, hanya akan ada satu deskripsi media data.
Arah
Setiap deskripsi audio atau video menjelaskan streaming Secure Real-time Transport
Protocol (SRTP) individual, yang diatur oleh RFC
3711. Deskripsi ini bersifat dua arah, sehingga memungkinkan dua peer mengirim dan menerima media melalui koneksi yang sama.
Oleh karena itu, setiap deskripsi media (dalam penawaran dan jawaban) berisi salah satu dari tiga atribut yang menjelaskan cara streaming harus digunakan:
sendonly: Hanya mengirim media dari peer penawaran. Peer jarak jauh tidak akan mengirim media di streaming ini.
recvonly: Hanya menerima media dari peer jarak jauh. Peer penawaran tidak akan mengirim media di streaming ini.
sendrecv: Kedua peer dapat mengirim dan menerima di streaming ini.
Codec
Setiap deskripsi media juga menentukan codec yang didukung peer. Dalam kasus
Meet Media API, penawaran klien akan ditolak kecuali jika mendukung
(setidaknya) codec yang ditentukan dalam persyaratan
teknis.
Handshake DTLS
Streaming SRTP diamankan oleh handshake awal
Datagram Transport Layer Security ("DTLS", RFC
9147) antara peer.
DTLS secara tradisional adalah protokol klien-ke-server; selama proses sinyal, satu peer setuju untuk bertindak sebagai server, sedangkan peer lainnya bertindak sebagai peer.
Karena setiap streaming SRTP mungkin memiliki koneksi DTLS khusus, setiap deskripsi media menentukan salah satu dari tiga atribut untuk menunjukkan peran peer dalam handshake DTLS:
a=setup:actpass: Peer penawaran akan mengikuti pilihan peer jarak jauh.
a=setup:active: Peer ini bertindak sebagai klien.
a=setup:passive: Peer ini bertindak sebagai server.
Deskripsi media aplikasi
Channel data (RFC 8831) adalah
abstraksi dari Stream Control Transmission Protocol ("SCTP", RFC
9260).
Untuk membuka channel data selama fase sinyal awal, penawaran harus berisi deskripsi media aplikasi. Tidak seperti deskripsi audio dan video, deskripsi aplikasi tidak menentukan arah atau codec.
Kandidat ICE
Kandidat Interactive Connectivity Establishment ("ICE", RFC
8445) peer adalah daftar
rute yang dapat digunakan peer jarak jauh untuk membuat koneksi.
Produk kartesius dari daftar dua peer, yang dikenal sebagai pasangan kandidat,
mewakili rute potensial antara dua peer. Pasangan ini diuji untuk menentukan rute yang optimal.
Berikut adalah penawaran dengan deskripsi media audio:
Gambar 1. Contoh penawaran dengan deskripsi media audio.
Peer jarak jauh merespons dengan jawaban
SDP yang berisi jumlah
baris deskripsi media yang sama. Setiap baris menunjukkan media apa, jika ada, yang dikirim kembali oleh peer jarak jauh ke klien penawaran di seluruh streaming SRTP. Peer jarak jauh juga dapat menolak streaming tertentu dari penawar dengan menetapkan entri deskripsi media tersebut ke recvonly.
Untuk Meet Media API, klien selalu mengirim penawaran SDP untuk memulai koneksi. Meet tidak pernah menjadi inisiator.
Perilaku ini dikelola secara internal oleh klien referensi
(C++, TypeScript),
tetapi developer klien kustom dapat menggunakan PeerConnectionInterface WebRTC untuk
membuat penawaran.
Untuk terhubung ke Meet, penawaran harus mematuhi persyaratan tertentu
requirements:
Klien harus selalu bertindak sebagai klien dalam handshake DTLS, sehingga setiap deskripsi media dalam penawaran harus menentukan a=setup:actpass atau a=setup:active.
Setiap baris deskripsi media harus mendukung semua codec
yang diperlukan untuk jenis media
tersebut:
Audio:Opus
Video:VP8, VP9, AV1
Untuk menerima audio, penawaran harus menyertakan tepat 3 deskripsi media audio hanya terima. Anda dapat melakukannya dengan menetapkan transceiver pada objek koneksi peer.
Untuk menerima video, penawaran harus menyertakan 1–3 deskripsi media video hanya terima. Anda dapat melakukannya dengan menetapkan transceiver pada objek koneksi peer.
Penawaran harus selalu menyertakan channel data. Minimal, channel session-control dan media-stats harus selalu terbuka. Semua channel data harus ordered.
Berikut adalah contoh lengkap penawaran SDP yang valid dan jawaban SDP yang cocok. Penawaran ini menegosiasikan sesi Meet Media API dengan audio dan satu streaming video.
Perhatikan bahwa ada tiga deskripsi media audio, satu deskripsi media video, dan deskripsi media aplikasi yang diperlukan.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2026-09-15 UTC."],[],[]]