Przeglądarka i telefon biurkowy mogą być dwoma końcami jednego połączenia, mimo że obsługują media w różny sposób.
Wybieranie między nimi traktuje funkcje celowo przypisane do jednej warstwy tak, jakby należały do drugiej.
Czy to są alternatywy?
Nie. Działają na różnych warstwach i każde z nich zostawia zadanie drugiego niewykonane.
SIP to sygnalizacja. Znajduje drugą stronę, negocjuje, jakie media zostaną wymienione, dzwoni, łączy i rozłącza. Nie przenosi dźwięku. RFC 3261 wyznacza granicę: "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 to stos mediów, który ma przeglądarka. Przenosi dźwięk i obraz między dwoma punktami końcowymi. Pokonuje translację adresów sieciowych, przez co bezpośrednia ścieżka między przeglądarkami jest trudna. Szyfruje również media. Jego własna specyfikacja, RFC 8825, dokument IETF Standards Track ze stycznia 2021, określa format mediów jako RTP. Wymaga SRTP: "Implementation of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is REQUIRED for all implementations".
SIP organizuje połączenia bez przenoszenia mediów. WebRTC przenosi media bez organizowania połączeń.
Co WebRTC pomija i dlaczego?
WebRTC pomija sygnalizację i robi to celowo: specyfikacja umieszcza wybór protokołu sygnalizacji poza własnym zakresem.
RFC 8825 opisuje ten układ jako trapez. Media wędrują bezpośrednio między dwiema przeglądarkami. Sygnalizacja wędruje przez serwery, które "can modify, translate, or manipulate the signals as needed". Specyfikacja nie wybiera protokołu sygnalizacji:
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.
To nie jest przeoczenie czekające na poprawkę. Dzięki temu aplikacja czatowa może sygnalizować przez własne wiadomości WebSocket, a platforma telefoniczna przez SIP, z tym samym stosem mediów pod spodem. Ten sam dokument wprost wymienia opcję telefoniczną, opisując wdrożenie, które używa "a standardized signaling mechanism (e.g., SIP over WebSockets)" między przeglądarką a serwerem.
SIP przez WebSocket jest zdefiniowany w RFC 7118 ze stycznia 2014, który definiuje "a WebSocket subprotocol as a reliable transport mechanism between SIP entities to enable use of SIP in web-oriented deployments". Zmienia sposób przesyłania wiadomości SIP, a nie ich treść, dlatego przeglądarka i telefon biurkowy mogą być dwoma końcami jednego zwykłego połączenia.
Jak to wygląda w Bird?
Aby połączyć przeglądarkę przez Bird, użyj SIP przez WebSocket.
Telefon wbudowany w dashboard to gotowy przykład. Przeglądarka działa jako klient SIP. Dashboard generuje dla niej krótkoterminowe poświadczenie sesji zamiast wysyłać długoterminowy sekret do strony. API opisuje handshake_token poświadczenia jako "Short-lived token required when upgrading the WebSocket connection". "authorizes the connection only; each call still authenticates with password". Token handshake autoryzuje połączenie, a hasło uwierzytelnia każde połączenie głosowe.
Kompatybilność przeglądarki zależy od algorytmów digest trunka. Przeglądarki odpowiadają na wyzwanie digest SIP algorytmem MD5 i niczym innym. Trunk akceptuje tylko algorytmy, które sam oferuje. Trunk skonfigurowany tak, by oferować wyłącznie SHA-256, odrzuca więc każde połączenie z przeglądarki, w tym telefon dashboardu. Pozostawienie MD5 w ofercie sprawia, że trunk jest dostępny z przeglądarki, a trunki SIP opisują to ustawienie.
Poza tym połączenie trafia na ten sam trunk, sprawdza ten sam zweryfikowany identyfikator dzwoniącego, stosuje te same dozwolone kierunki i generuje ten sam rekord co połączenie z PBX, czyli centrali telefonicznej, która kieruje połączenia w firmie.
Więc czego użyć?
Wybierz w zależności od tego, gdzie działa Twój punkt końcowy, i licz się z użyciem SIP w każdym przypadku.
WebRTC wymaga szyfrowania mediów. Transport TLS trunka SIP szyfruje sygnalizację w trakcie przesyłania, a nie dźwięk. Przegląd szyfrowania musi więc obejmować obie ścieżki.
- Przeglądarka. Strona korzysta ze stosu WebRTC przeglądarki do obsługi mediów, więc ta połowa jest rozwiązana. Wybierasz sposób sygnalizacji. SIP łączy ją z siecią telefoniczną, a nie tylko z innymi przeglądarkami.
- Telefon biurkowy, PBX lub kontroler sesji brzegowych (SBC), który kontroluje połączenia na granicy sieci. Zwykły SIP przez UDP, TCP lub TLS. WebRTC nie ma nic do zaoferowania sprzętowi, który już posługuje się RTP.
- Głosowy agent AI. Zależy od tego, co Twoje środowisko uruchomieniowe już implementuje. Agent w przeglądarce lub w środowisku zbudowanym wokół przeglądarkowych API mediów będzie posługiwał się WebRTC i potrzebuje dołączonej sygnalizacji. Agent zbudowany na stosie telefonicznym posługuje się SIP i RTP bezpośrednio. Czym jest głosowy agent AI obejmuje resztę tej ścieżki, w tym część, w której agent musi terminować dźwięk, a nie tylko sygnalizację.
W skrócie
Pytanie porównuje dwie różne warstwy.
WebRTC to stos mediów dla przeglądarek, bez protokołu sygnalizacji. SIP to protokół sygnalizacji, który nie przenosi mediów. Żadne z nich nie zastępuje drugiego.
WebRTC celowo pomija sygnalizację.
Jego własny opis umieszcza wybór protokołu sygnalizacji poza zakresem specyfikacji i wymienia SIP przez WebSocket jako jeden ze standardowych sposobów wypełnienia tej luki.
Połączenie z przeglądarki przez Bird to połączenie SIP.
Przeglądarka działa jako klient SIP, połączenie jest uaktualniane do WebSocket z krótkoterminowym tokenem, a każde połączenie nadal uwierzytelnia się hasłem digest.
Szyfrowanie znajduje się w różnych miejscach w każdym z nich.
WebRTC wymaga SRTP dla mediów. Transport TLS trunka SIP szyfruje sygnalizację, co jest czymś innym niż szyfrowanie dźwięku.