SDP — apa itu, format deskripsi sesi dan peran dalam WebRTC

Apa itu SDP (Session Description Protocol)?

SDP — adalah protokol lapisan aplikasi yang ditujukan untuk mendeskripsikan parameter sesi multimedia dalam format teks. Ini dikembangkan dalam kerangka kelompok kerja MMUSIC (Multiparty Multimedia Session Control) IETF dan pertama kali distandarisasi di RFC 2327 pada tahun 1998. Pada tahun 2021, spesifikasi terkini RFC 8866 diterbitkan, menggantikan versi sebelumnya RFC 4566.

Tugas utama SDP adalah memberikan peserta sesi semua informasi yang diperlukan untuk membangun koneksi: aliran media apa yang akan dikirim, codec apa yang didukung, melalui alamat jaringan dan port mana transmisi akan dilakukan. SDP tidak mengirimkan data media itu sendiri, hanya mendeskripsikan bagaimana koneksi harus diatur.

Menurut IETF RFC 8866, format SDP terdiri dari serangkaian baris, masing-masing dimulai dengan tipe satu huruf, diikuti oleh tanda sama dengan dan nilai. Misalnya, baris m=audio 5004 RTP/AVP 0 berarti sesi tersebut mencakup aliran audio di port 5004 dengan protokol transportasi RTP/AVP dan codec PCMU (tipe 0).

Sejarah dan standardisasi SDP

Versi pertama SDP diterbitkan di RFC 2327 pada April 1998 sebagai hasil kerja kelompok MMUSIC. Protokol ini awalnya dibuat untuk mengumumkan sesi multicast dalam kerangka Mbone (Multicast Backbone). Dengan perkembangan VoIP dan konferensi video, cakupan aplikasi SDP meluas, dan pada tahun 2006 spesifikasi yang diperbarui RFC 4566 diterbitkan.

Terobosan nyata dalam penggunaan SDP terjadi dengan munculnya WebRTC pada tahun 2011. Google mengintegrasikan SDP sebagai mekanisme utama deskripsi sesi media dalam kerangka kerja komunikasi real-time browser. Sejak saat itu, SDP menjadi komponen wajib dari setiap implementasi WebRTC — dari browser hingga aplikasi mobile di iOS dan Android.

Pada tahun 2021, kelompok kerja IETF menerbitkan RFC 8866 — spesifikasi SDP terkini yang menggantikan RFC 4566. Versi yang diperbarui memperjelas penanganan ICE (Interactive Connectivity Establishment), dukungan untuk DTLS (Datagram Transport Layer Security), dan memperluas kemampuan deskripsi sesi grup.

Perbedaan SDP dari protokol transportasi

SDP pada dasarnya berbeda dari protokol transportasi karena tidak berpartisipasi dalam transmisi data. Ini hanya menjalankan fungsi deskriptif — mirip dengan metadata file multimedia. Sementara RTP (Real-time Transport Protocol) mengirimkan paket audio dan video, dan RTCP mengontrol kualitas transmisi, SDP hanya menunjukkan codec dan port mana yang akan digunakan.

Analogi dari pengembangan web: SDP adalah markup HTML yang mendeskripsikan struktur halaman, dan RTP adalah gambar dan teks itu sendiri. Tanpa SDP, peserta sesi tidak tahu cara terhubung satu sama lain, bahkan jika koneksi jaringan sudah terbentuk. Mekanisme NAT-traversal (ICE) juga mengandalkan SDP untuk mengirimkan informasi tentang kandidat jaringan.

Bagaimana struktur SDP disusun

Struktur SDP diatur sebagai urutan baris teks, masing-masing mengikuti format type=value. Tipe satu huruf menentukan tujuan baris, dan nilai berisi nilai yang sesuai. Semua baris dipisahkan oleh karakter baris baru CRLF.

Standar RFC 8866 mendefinisikan beberapa bidang wajib dan opsional. Bidang wajib mencakup versi protokol (v=), nama sesi (s=), waktu mulai dan berakhirnya sesi (t=). Bidang lainnya bersifat opsional, tetapi untuk sesi WebRTC, deskripsi media (m=), atribut (a=), dan informasi jaringan (c=) juga diperlukan.

v=0
o=- 46116397 2 IN IP4 192.168.1.100
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 5004 RTP/SAVPF 111 103 104
c=IN IP4 192.168.1.100
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
m=video 5006 RTP/SAVPF 96 97
a=rtpmap:96 VP8/90000
a=rtpmap:97 H264/90000

Dalam contoh di atas, diperlihatkan segmen SDP tipikal untuk sesi WebRTC. Baris v=0 menunjukkan versi protokol. Bidang o= berisi pengidentifikasi pemilik sesi dan versinya. Baris s=- menetapkan nama sesi (tanda hubung berarti nama kosong). Bidang t=0 0 menunjukkan bahwa sesi tidak dibatasi waktu.

Bidang a=group:BUNDLE audio video adalah atribut yang mengelompokkan beberapa aliran media ke dalam satu saluran transportasi. Mekanisme BUNDLE memungkinkan penghematan sumber daya jaringan dengan mengirimkan audio dan video melalui satu koneksi. Ini sangat penting untuk perangkat mobile dengan bandwidth terbatas.

Bidang wajib SDP

Spesifikasi RFC 8866 mendefinisikan serangkaian bidang wajib dan opsional. Bidang wajib mencakup v= (versi), s= (nama sesi) dan t= (waktu). Bidang o= (pemilik), meskipun tidak sepenuhnya wajib menurut RFC, praktis selalu ada dalam implementasi nyata.

Bidang m= (media) adalah salah satu yang terpenting. Bidang ini mendeskripsikan aliran media tertentu dan berisi tipe media (audio, video, text, application), port, protokol transportasi, dan daftar codec yang didukung. Di WebRTC, tipe yang paling sering digunakan adalah audio dan video dengan protokol transportasi RTP/SAVPF (Secure Audio/Video Profile with Feedback) atau UDP/TLS/RTP/SAVPF.

Bidang a= (attribute) adalah yang paling fleksibel dan dapat diperluas. Ini dapat berisi rtpmap (pemetaan nomor codec ke nama), fmtp (parameter codec), fingerprint (sidik jari kunci DTLS), ice-ufrag dan ice-pwd (kredensial ICE) dan banyak atribut lainnya. Melalui atribut-atribut inilah SDP mendukung mekanisme keamanan modern dan NAT-traversal.

Bagaimana SDP bekerja di WebRTC

Dalam arsitektur WebRTC, SDP berperan sebagai protokol pensinyalan untuk mendeskripsikan dan menegosiasikan parameter sesi media antara dua peserta. SDP sendiri tidak mendefinisikan mekanisme transmisi deskripsi ini — tugas ini diselesaikan oleh saluran pensinyalan yang diimplementasikan secara independen oleh pengembang melalui WebSocket, HTTP, atau protokol lainnya.

Proses dimulai dengan pembuatan penawaran SDP — Offer oleh inisiator (penelepon). Untuk ini, browser memanggil metode createOffer() pada objek RTCPeerConnection. Deskripsi SDP yang dihasilkan berisi semua parameter sesi dari pihak inisiator: codec yang didukung, alamat jaringan, kandidat ICE, dan persyaratan keamanan.

const configuration = { iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] };
const pc = new RTCPeerConnection(configuration);

// Buat Penawaran SDP di Android
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Kirim string SDP ke rekan jarak jauh
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// Send SDP to remote peer via signaling channel
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

Setelah pembuatan Offer dan pengaturan deskripsi lokal melalui setLocalDescription(), inisiator mengirimkan string SDP ke peserta jarak jauh melalui saluran pensinyalan. Peserta jarak jauh, setelah menerima SDP Offer, membuat respons SDP — Answer — dan mengirimkannya kembali. Pertukaran ini disebut pertukaran pensinyalan (signaling exchange) dan merupakan langkah wajib sebelum pembentukan koneksi peer-to-peer.

Menurut Spesifikasi W3C WebRTC, pertukaran SDP harus terjadi sebelum pertukaran kandidat ICE dimulai. Dalam praktiknya, banyak implementasi mengirimkan kandidat ICE secara paralel dengan SDP, menggunakan mekanisme ICE trickle. Ini mengurangi waktu pembentukan koneksi, terutama untuk jaringan mobile dengan latensi tinggi.

Peran ICE dalam SDP

ICE (Interactive Connectivity Establishment) — adalah mekanisme yang menggunakan atribut SDP untuk mengirimkan informasi tentang kandidat jaringan. Kandidat ICE mendeskripsikan jalur koneksi yang mungkin: host (alamat lokal), srflx (alamat setelah NAT, diperoleh melalui STUN) dan relay (alamat server TURN).

Dalam SDP, kandidat ICE dikirim melalui atribut a=candidate:, serta melalui bidang ice-ufrag dan ice-pwd untuk autentikasi lalu lintas ICE. Setiap kandidat mencakup protokol transportasi (UDP, TCP), alamat IP, port, dan prioritas. Koneksi yang berhasil dibangun melalui kandidat pertama yang lulus tes konektivitas. Mekanisme ICE restart memungkinkan pembaruan koneksi saat jaringan berubah.

Untuk aplikasi mobile, kandidat ICE sangat penting karena perangkat sering berada di belakang NAT atau firewall perusahaan. Mekanisme ICE memungkinkan penemuan jalur yang berfungsi bahkan dalam kondisi jaringan yang kompleks, dan SDP berfungsi sebagai wadah transportasi untuk informasi ini.

Keamanan SDP di WebRTC

SDP di WebRTC wajib menyertakan atribut keamanan, khususnya sidik jari DTLS (fingerprint) dan parameter SRTP. Bidang a=fingerprint:sha-256 berisi sidik jari sertifikat DTLS yang digunakan untuk autentikasi dan enkripsi aliran media. Tanpa atribut ini, koneksi WebRTC tidak akan terbentuk.

Mekanisme keamanan tambahan mencakup atribut a=setup:, yang menentukan peran jabat tangan DTLS (active, passive, actpass), dan a=ice-lite: untuk implementasi ICE yang disederhanakan di sisi server. Semua parameter ini dikirim dalam SDP dan diperiksa oleh kedua belah pihak sebelum transmisi data media dimulai.

Tipe SDP: Offer dan Answer

Dalam model WebRTC, ada dua jenis pesan SDP: Offer (penawaran) dan Answer (jawaban). Offer dibuat oleh inisiator koneksi dan berisi deskripsi lengkap sesi media yang diinginkan. Answer dibuat oleh peserta jarak jauh sebagai respons terhadap Offer dan berisi kemampuannya dengan mempertimbangkan batasan yang diberlakukan oleh penawaran.

Perbedaan utama antara Offer dan Answer terletak pada semantik atribut. Offer mendaftar semua codec, protokol transportasi, dan alamat jaringan yang didukung yang dapat ditawarkan inisiator. Answer memilih subset dari kemampuan ini yang didukung oleh pihak jarak jauh. Misalnya, jika Offer menawarkan opus, ISAC, dan PCMU, Answer dapat memilih hanya opus sebagai codec yang paling disukai.

Proses pertukaran diatur oleh spesifikasi W3C WebRTC dan mencakup beberapa status RTCPeerConnection. Setelah pembuatan Offer melalui createOffer() dan pengaturannya sebagai deskripsi lokal, koneksi masuk ke status have-local-offer. Setelah penerimaan Answer dan pengaturannya sebagai deskripsi jarak jauh melalui setRemoteDescription(), koneksi masuk ke stable — status akhir yang siap untuk transmisi media.

Penggunaan SDP dalam SDK mobile

SDK mobile untuk WebRTC — Google WebRTC untuk Android dan WebRTC.framework untuk iOS — sepenuhnya mendukung pertukaran SDP melalui Offer dan Answer. Di Android, untuk membuat Offer digunakan kelas PeerConnection dengan metode createOffer(), mirip dengan API browser. Deskripsi SDP yang diperoleh dikirim sebagai string melalui saluran pensinyalan.

Di iOS, bekerja dengan SDP dilakukan melalui kelas RTCSessionDescription dari framework WebRTC. Saat inisialisasi, tipe (RTCSdpTypeOffer atau RTCSdpTypeAnswer) dan string SDP ditentukan. Platform secara otomatis mengurai SDP dan mengonfigurasi koneksi sesuai dengan parameter yang dikirim.

val configuration = PeerConnection.RTCConfiguration(List())
val peerConnection = factory.createPeerConnection(configuration, object : PeerConnection.Observer {
    override fun onIceCandidate(candidate: IceCandidate) { }
})

// Create SDP Offer on Android
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // Send SDP string to remote peer
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

Kemampuan untuk bekerja langsung dengan string SDP memberikan fleksibilitas kepada pengembang: mereka dapat memodifikasi SDP sebelum pengiriman, menambah atau menghapus codec tertentu, mengonfigurasi parameter ICE, atau menambahkan atribut kustom. Untuk aplikasi Android, seringkali diperlukan untuk menonaktifkan video di SDP saat bandwidth jaringan rendah — ini dilakukan dengan menghapus baris m= yang sesuai dari deskripsi SDP.

SDP dalam pengembangan mobile

Dalam pengembangan mobile, SDP terutama digunakan dalam konteks WebRTC — untuk membuat aplikasi dengan panggilan video, obrolan suara, dan streaming. Aplikasi mobile di Android dan iOS dapat bertindak sebagai inisiator maupun penerima pesan SDP, memungkinkan pembangunan koneksi peer-to-peer yang simetris.

Kekhasan aplikasi mobile adalah kebutuhan untuk bekerja dengan SDP dalam kondisi kualitas jaringan yang bervariasi. Saat beralih antara Wi-Fi dan internet mobile, serta saat bandwidth berubah, mungkin diperlukan pembuatan deskripsi SDP baru. Untuk ini, digunakan mekanisme renegotiation — pertukaran SDP berulang melalui createOffer() dan setLocalDescription().

Menurut tim Google WebRTC (2023), optimalisasi pertukaran SDP untuk perangkat mobile mencakup penggunaan ICE restart saat jaringan berubah, prioritisasi codec dengan bitrate rendah (opus untuk audio, VP8 untuk video), dan ukuran string SDP minimal dengan mengecualikan aliran media yang tidak perlu. Keuntungan utamanya adalah pengurangan latensi dalam pembentukan koneksi di jaringan mobile.

Optimalisasi SDP untuk jaringan mobile

Salah satu tugas utama saat bekerja dengan SDP di perangkat mobile adalah meminimalkan ukuran deskripsi SDP. SDP lengkap untuk sesi WebRTC tipikal dengan audio dan video dapat memakan 2–5 KB, yang signifikan untuk jaringan lambat. Optimalisasi mencakup penggunaan BUNDLE (penggabungan aliran), penghapusan codec yang tidak didukung, dan kompresi kandidat ICE.

Masalah tambahan perangkat mobile adalah masa pakai SDP yang terbatas. Dalam kondisi koneksi tidak stabil, SDP dapat kedaluwarsa sebelum peserta jarak jauh berhasil memprosesnya. Solusinya adalah menggunakan waktu tunggu pendek untuk menerima Answer dan mengirim ulang SDP jika diperlukan. Mekanisme ICE restart memungkinkan pembaruan koneksi tanpa pembuatan ulang RTCPeerConnection secara penuh. Atribut a=ice-lite menyederhanakan implementasi ICE di sisi server.

Pustaka populer untuk bekerja dengan SDP

Pengembang aplikasi mobile memiliki akses ke pustaka siap pakai yang menyederhanakan pekerjaan dengan SDP. libjingle_peerconnection (Google WebRTC) — pustaka utama untuk Android, menyediakan API lengkap untuk manajemen SDP. Untuk iOS, digunakan WebRTC.framework dengan fungsionalitas serupa. Kedua pustaka secara otomatis menghasilkan dan mengurai SDP, tetapi memberikan akses ke string SDP mentah jika diperlukan.

Untuk kontrol yang lebih halus atas SDP, ada solusi pihak ketiga: sdp-transform (JavaScript atau Node.js) untuk mengurai dan memodifikasi SDP, NICENICE (Java) untuk bekerja dengan kandidat ICE, dan SDK siap pakai dari penyedia infrastruktur WebRTC yang menangani seluruh pertukaran pensinyalan, termasuk SDP.