Browser dan telepon meja bisa menjadi dua ujung dari satu panggilan meskipun keduanya menangani media secara berbeda.
Memilih di antara keduanya memperlakukan fitur yang sengaja ditempatkan di satu lapisan seolah-olah fitur tersebut milik lapisan lain.
Apakah keduanya alternatif?
Tidak. Keduanya berada di lapisan yang berbeda dan masing-masing tidak menangani tugas yang lain.
SIP adalah signaling. Ia menemukan ujung tujuan, menegosiasikan media apa yang akan dipertukarkan, membunyikan dering, menyambungkan, dan memutuskan. Ia tidak membawa audio. RFC 3261 menetapkan batasannya: "SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture."
WebRTC adalah stack media yang dimiliki browser. Ia membawa audio dan video antara dua endpoint. Ia melewati network address translation, yang menjadi alasan jalur langsung antar-browser sulit dicapai. Ia juga mengenkripsi media. Spesifikasinya sendiri, RFC 8825, dokumen IETF Standards Track dari Januari 2021, menyatakan format medianya adalah RTP. Ia mewajibkan SRTP: "Implementation of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is REQUIRED for all implementations".
SIP mengatur panggilan tanpa membawa media. WebRTC membawa media tanpa mengatur panggilan.
Apa yang tidak dicakup WebRTC, dan mengapa?
WebRTC tidak mencakup signaling, dan ini dilakukan dengan sengaja: spesifikasinya menempatkan pilihan protokol signaling di luar cakupannya sendiri.
RFC 8825 menggambarkan susunan ini sebagai trapesium. Media berjalan langsung antara dua browser. Signaling berjalan melalui server, yang "can modify, translate, or manipulate the signals as needed". Spesifikasi ini tidak memilih protokol signaling:
The choice of protocols for client-server and inter-server signaling, and the definition of the translation between them, are outside the scope of the WebRTC protocol suite described in this document.
Ini bukan kelalaian yang menunggu untuk diperbaiki. Inilah yang memungkinkan aplikasi chat melakukan signaling melalui pesan WebSocket-nya sendiri sementara platform telefoni melakukan signaling melalui SIP, dengan stack media yang sama di bawah keduanya. Dokumen yang sama menyebut opsi telefoni secara langsung, mendeskripsikan deployment yang menggunakan "a standardized signaling mechanism (e.g., SIP over WebSockets)" antara browser dan server.
SIP over WebSocket ditetapkan dalam RFC 7118, dari Januari 2014, yang mendefinisikan "a WebSocket subprotocol as a reliable transport mechanism between SIP entities to enable use of SIP in web-oriented deployments". Ia mengubah cara pesan SIP berjalan, bukan isinya, sehingga browser dan telepon meja bisa menjadi dua ujung dari satu panggilan biasa.
Seperti apa tampilannya di Bird?
Untuk menghubungkan browser melalui Bird, gunakan SIP over WebSocket.
Telepon bawaan dashboard adalah contoh penerapannya. Browser bertindak sebagai klien SIP. Dashboard membuat kredensial sesi berdurasi pendek untuk browser tersebut alih-alih mengirimkan secret berdurasi panjang ke dalam halaman. API mendeskripsikan handshake_token kredensial tersebut sebagai "Short-lived token required when upgrading the WebSocket connection". Ia "authorizes the connection only; each call still authenticates with password". Token handshake mengotorisasi koneksi, sementara password mengautentikasi setiap panggilan.
Kompatibilitas browser bergantung pada algoritma digest trunk. Browser menjawab digest challenge SIP dengan MD5 dan tidak yang lain. Trunk hanya menerima algoritma yang ditawarkannya. Trunk yang dikonfigurasi untuk menawarkan SHA-256 saja akan menolak setiap panggilan browser, termasuk telepon dashboard. Menyertakan MD5 dalam penawaran adalah yang membuat trunk dapat dipanggil dari browser, dan SIP trunks membahas pengaturan ini.
Panggilan tersebut tetap mendarat di trunk yang sama, memeriksa caller ID terverifikasi yang sama, mematuhi tujuan yang diaktifkan yang sama, dan menghasilkan catatan yang sama seperti panggilan dari PBX, sistem telepon bisnis yang merutekan panggilan perusahaan.
Jadi mana yang saya gunakan?
Pilih berdasarkan tempat endpoint Anda berjalan, dan bersiaplah menggunakan SIP dalam kedua kasus.
WebRTC mewajibkan media terenkripsi. Transport TLS pada trunk SIP mengenkripsi signaling dalam transit, bukan audio. Tinjauan enkripsi oleh karena itu perlu mencakup kedua jalur.
- Browser. Halaman web menggunakan stack WebRTC browser untuk media, jadi bagian itu sudah pasti. Anda memilih cara melakukan signaling-nya. SIP menghubungkannya ke jaringan telepon, bukan hanya ke browser lain.
- Telepon meja, PBX, atau session border controller (SBC), yang mengontrol panggilan di batas jaringan. SIP biasa melalui UDP, TCP, atau TLS. WebRTC tidak menawarkan apa pun untuk perangkat yang sudah berbicara RTP.
- Voice AI agent. Pilih sesuai yang sudah diimplementasikan runtime Anda. Agent di browser atau di runtime berbasis API media browser akan berbicara WebRTC dan membutuhkan signaling yang dilampirkan. Agent yang dibangun di atas stack telefoni berbicara SIP dan RTP secara langsung. What is a voice AI agent membahas sisa jalur tersebut, termasuk bagian di mana agent harus menerminasi audio, bukan hanya signaling.
Singkatnya
Pertanyaan ini membandingkan dua lapisan yang berbeda.
WebRTC adalah stack media untuk browser tanpa protokol signaling. SIP adalah protokol signaling yang tidak membawa media. Keduanya tidak saling menggantikan.
WebRTC sengaja tidak mencakup signaling.
Ringkasan spesifikasinya sendiri menempatkan pilihan protokol signaling di luar cakupan spesifikasi, dan menyebut SIP over WebSockets sebagai salah satu cara standar untuk mengisi celah tersebut.
Panggilan browser melalui Bird adalah panggilan SIP.
Browser bertindak sebagai klien SIP, koneksi di-upgrade ke WebSocket dengan token berdurasi pendek, dan setiap panggilan tetap diautentikasi dengan digest password.
Enkripsi berada di tempat yang berbeda pada masing-masing.
WebRTC mewajibkan SRTP untuk media. Transport TLS pada trunk SIP mengenkripsi signaling, yang merupakan hal terpisah dari audio.