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 membangun langsung di atasnya.
Namun, Anda juga dapat membuat klien WebRTC yang sepenuhnya kustom yang mematuhi persyaratan
teknis Meet Media API.
Halaman ini menguraikan konsep utama WebRTC 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 aliran audio n, penawar menyertakan deskripsi media audio n
dalam penawaran. Hal yang sama berlaku untuk video. Namun, paling banyak hanya ada satu deskripsi media data.
Arah
Setiap deskripsi audio atau video menjelaskan setiap aliran Secure Real-time Transport Protocol (SRTP), yang diatur oleh RFC
3711. Koneksi 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 penggunaan streaming:
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 yang menawarkan tidak akan mengirim media di streaming ini.
sendrecv: Kedua peer dapat mengirim dan menerima di aliran ini.
Codec
Setiap deskripsi media juga menentukan codec yang didukung peer. Dalam kasus
Meet Media API, penawaran klien ditolak kecuali jika mendukung
(setidaknya) codec yang ditentukan dalam persyaratan
teknis.
Handshake DTLS
Streaming SRTP diamankan oleh handshake
Datagram Transport Layer Security ("DTLS", RFC
9147) awal antara peer.
DTLS biasanya merupakan protokol client-to-server; selama proses pensinyalan,
satu peer setuju untuk bertindak sebagai server, sementara peer lainnya bertindak sebagai peer.
Karena setiap aliran 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 menunda pilihan peer
jarak jauh.
a=setup:active: Peer ini bertindak sebagai klien.
a=setup:passive: Peer ini bertindak sebagai server.
Deskripsi media aplikasi
Saluran data (RFC 8831) adalah
abstraksi dari Stream Control Transmission Protocol ("SCTP", RFC
9260).
Untuk membuka saluran data selama fase pemberian 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 kedua peer, yang dikenal sebagai pasangan kandidat,
mewakili potensi rute 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 melalui aliran SRTP. Peer jarak jauh
juga dapat menolak aliran tertentu dari penawar dengan menyetel entri deskripsi
media tersebut ke recvonly.
Untuk Meet Media API, klien selalu mengirimkan 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 Meet, penawaran harus mematuhi
persyaratan tertentu:
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 menyetel transceiver pada objek koneksi peer.
Untuk menerima video, penawaran harus menyertakan 1–3 deskripsi media video hanya terima. Anda dapat melakukannya dengan menyetel transceiver pada objek koneksi peer.
Penawaran harus selalu menyertakan saluran data. Minimal, saluran
session-control dan media-stats harus selalu terbuka. Semua saluran 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 aliran
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-05-13 UTC."],[],[]]