Um navegador e um telefone de mesa podem ser as duas pontas de uma mesma chamada, mesmo tratando a mídia de formas diferentes.
Escolher entre eles trata funcionalidades deliberadamente atribuídas a uma camada como se pertencessem à outra.
Eles são alternativas?
Não. Eles ficam em camadas diferentes e cada um deixa a função do outro por fazer.
SIP é sinalização. Ele encontra a outra ponta, negocia qual mídia será trocada, toca, conecta e encerra. Ele não transporta o áudio. A RFC 3261 traça o limite: "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 é a pilha de mídia que um navegador possui. Ele transporta áudio e vídeo entre dois endpoints. Ele atravessa tradução de endereços de rede (NAT), que é o que torna difícil um caminho direto entre navegadores. Ele também criptografa a mídia. Sua própria especificação, a RFC 8825, um documento Standards Track do IETF de janeiro de 2021, diz que o formato de mídia é RTP. Ele exige SRTP: "Implementation of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is REQUIRED for all implementations".
O SIP organiza chamadas sem transportar mídia. O WebRTC transporta mídia sem organizar chamadas.
O que o WebRTC deixa de fora, e por quê?
O WebRTC deixa de fora a sinalização, e faz isso deliberadamente: a especificação coloca a escolha do protocolo de sinalização fora do seu próprio escopo.
A RFC 8825 descreve o arranjo como um trapezoide. A mídia viaja diretamente entre os dois navegadores. A sinalização viaja pelos servidores, que "can modify, translate, or manipulate the signals as needed". A especificação não escolhe um protocolo de sinalização:
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.
Isso não é uma omissão esperando ser corrigida. É o que permite que um aplicativo de chat sinalize por suas próprias mensagens WebSocket enquanto uma plataforma de telefonia sinaliza via SIP, com a mesma pilha de mídia por baixo de ambos. O mesmo documento menciona a opção de telefonia diretamente, descrevendo uma implantação que usa "a standardized signaling mechanism (e.g., SIP over WebSockets)" entre o navegador e o servidor.
SIP sobre WebSocket é especificado na RFC 7118, de janeiro de 2014, que define "a WebSocket subprotocol as a reliable transport mechanism between SIP entities to enable use of SIP in web-oriented deployments". Ele muda como as mensagens SIP trafegam e não o que elas dizem, e é por isso que um navegador e um telefone de mesa podem ser as duas pontas de uma chamada comum.
Como isso funciona no Bird?
Para conectar um navegador pelo Bird, use SIP sobre um WebSocket.
O telefone do próprio dashboard é o exemplo prático. O navegador atua como cliente SIP. O dashboard gera uma credencial de sessão de curta duração para ele, em vez de enviar um segredo de longa duração para a página. A API descreve o handshake_token da credencial como um "Short-lived token required when upgrading the WebSocket connection". Ele "authorizes the connection only; each call still authenticates with password". O token do handshake autoriza a conexão, enquanto a senha autentica cada chamada.
A compatibilidade do navegador depende dos algoritmos digest do trunk. Os navegadores respondem a um desafio digest SIP com MD5 e nada mais. Um trunk aceita apenas os algoritmos que ele oferece. Um trunk configurado para oferecer somente SHA-256 recusa, portanto, todas as chamadas de navegador, incluindo o telefone do dashboard. Manter MD5 na oferta é o que torna um trunk chamável a partir de um navegador, e trunks SIP cobre essa configuração.
A chamada, fora isso, cai no mesmo trunk, verifica o mesmo identificador de chamadas verificado, obedece aos mesmos destinos habilitados e gera o mesmo registro que uma chamada de um PBX, o sistema telefônico empresarial que roteia as chamadas de uma empresa.
Então, qual eu uso?
Escolha de acordo com onde seu endpoint roda, e espere usar SIP de qualquer forma.
O WebRTC exige mídia criptografada. O transporte TLS de um trunk SIP criptografa a sinalização em trânsito, e não o áudio. Uma análise de criptografia, portanto, precisa cobrir ambos os caminhos.
- Um navegador. Uma página web usa a pilha WebRTC do navegador para a mídia, então essa metade está resolvida. Você escolhe como sinalizar. O SIP conecta à rede telefônica, e não apenas a outros navegadores.
- Um telefone de mesa, um PBX ou um session border controller (SBC), que controla chamadas na fronteira de uma rede. SIP puro sobre UDP, TCP ou TLS. O WebRTC não tem nada a oferecer a equipamentos que já falam RTP.
- Um agente de IA de voz. O que seu runtime já implementar. Um agente em um navegador ou em um runtime construído em torno de APIs de mídia de navegador vai falar WebRTC e precisa de sinalização acoplada. Um agente construído sobre uma pilha de telefonia fala SIP e RTP diretamente. O que é um agente de IA de voz cobre o restante desse caminho, incluindo a parte em que o agente precisa terminar o áudio e não apenas a sinalização.
Em resumo
A pergunta compara duas camadas diferentes.
O WebRTC é uma pilha de mídia para navegadores sem protocolo de sinalização. O SIP é um protocolo de sinalização que não transporta mídia. Nenhum substitui o outro.
O WebRTC deixa a sinalização de fora deliberadamente.
Sua própria visão geral coloca a escolha do protocolo de sinalização fora do escopo da especificação e menciona SIP sobre WebSockets como uma forma padrão de preencher essa lacuna.
Uma chamada de navegador via Bird é uma chamada SIP.
O navegador atua como cliente SIP, a conexão é promovida a um WebSocket com um token de curta duração, e cada chamada ainda se autentica com uma senha digest.
A criptografia fica em lugares diferentes em cada um.
O WebRTC exige SRTP para a mídia. O transporte TLS de um trunk SIP criptografa a sinalização, que é algo separado do áudio.