É possível fazer uma aplicação de chat de vídeo sem servidor com WebRTC?

Eu acho que "parcialmente" é'não é possível configurar uma conexão WebRTC sem nenhum meio; WebRTC depende inteiramente do modelo de oferta/resposta e WebRTC pode'não pule para enfrentar clientes NAT porque NATs é uma verdade universal que está se tornando cada vez mais complexa a cada dia.

Embora, é possível gerar e adicionar candidatos ICE na hora; no entanto, como você'vai reunir e usar portas UDP? Obviamente você precisa contar com plugins "nativos" de terceiros ou servidores/serviços públicos.

Descrições de sessões podem ser copiadas/coladas entre duas abas, no entanto eu não'não acho que seja possível trocá-las entre dois computadores/rede únicos sem nenhum meio/médio.

Em palavras simples, você sempre precisa de uma maneira de obter portas UDP e endereços ipv4/ipv6, você também precisa trocar metadados de mídia entre usuários usando qualquer gateway personalizado ou de terceiros.

Uma pessoa pode levantar uma questão, "podemos reutilizar uma descrição de sessão? Pessoalmente eu penso parcialmente "Sim' e parcialmente "Não".

Para "sim", eu quis dizer que o navegador pode gerar faixas idênticas, ou seja, linhas ssrc na recarga da página, também o navegador pode usar os mesmos candidatos até passarmos manualmente as restrições obrigatórias "IceRestart:true".

Para "não", eu quis dizer que SDP não é apenas sobre trilhas de mídia e portas UDP predefinidas; é sobre tudo o que é necessário para o estabelecimento de conexão segura se são chaves criptografadas (impressões digitais) usadas para o acordo de chaves DTLS/SRTP; e muito mais.

Agora, voltando ao seu ponto, como no XMPP, é possível gerar/recolher ICE a partir do mesmo gateway de sinalização que é usado para troca de metadados das sessões; você pode injetar ICE dinamicamente coletado no SDP de saída e adicionar localmente usando o método "addIceCandidate" entretanto você precisa de pelo menos um servidor público/privado.

Quando falamos de LAN, normalmente usamos socketio para trocar ofertas/respostas; então candidatos de host/local são usados para estabelecimento de conexão. Este cenário só é útil se ambos os usuários estiverem sentados atrás da mesma rede.

No cenário LAN, é possível usar o mecanismo copiar/colar, no entanto você'sempre precisará de um meio/médio para compartilhar os dados copiados.

Remember, WebRTC é't "apenas" uma coleção de API orientada ao navegador; é uma inovação no campo de desenvolvimento web onde os melhores protocolos e regras são usados para configurar conexão direta de mídia/dados entre dois ou mais dispositivos sentados atrás de redes diferentes/idênticas. Você pode seguir as especificações do RTCWeb para implementações personalizadas e pode usar motores de mídia proprietários/de código aberto (e codificadores/descodificadores) junto com o RTCWeb API para trazer uma estrutura mais produtiva comparando os fornecedores WebRTC tradicionais.

Significa que você pode escrever aplicações nativas para reunir/gerar candidatos/descrições em seu nível de aplicação NATIVE; entretanto você'precisará "sempre" de um meio para trocar os dados de um usuário's com outros.

Agora, pode surgir outra pergunta, "e se todo o procedimento de A-to-Z for tratado pelo fornecedor do navegador; e a aplicação apenas usar API orientada a objetos para configurar a conexão?"

Resposta simples: Os fornecedores de navegadores também precisam de alguns meios para usar na busca de portas, estabelecimento de conexão criptografada e troca de metadados.

Não é possível compartilhar algo diretamente com outro computador sem usar nenhum meio.

Quando a conexão entre pares é estabelecida, estamos usando um meio, ou seja, portas UDP para trocar dados multiplexados, ou seja, pacotes codificados RTP/RTCP entre dois usuários.

100% menos conexão do servidor só é possível se você've portas UDP "ativas" do usuário alvo; você também sabe os endereços ipv4/ipv6 do usuário alvo; também você've chave(s) criptografada(s) do usuário alvo que podem ser usadas para configuração de conexão DTLS; também seu navegador pode decodificar pacotes RTP/RTCP vindos de outro usuário.

Vamos dizer que o target peer é um servidor de mídia, que é codificado para codificar buffers de áudio em codecs speex; então como o seu navegador pode decodificar e reproduzir buffers?

Or se o target peer está usando o protocolo RTP para conexão de dados; e seu navegador, ou seja, Firefox entende apenas SCTP; então como você'irá capturar/decodificar e entender os dados recebidos?

Or se target peer's browser bundled/multiplexed packets over single UDP port; how your browser can understand/decode those packets if it has no idea about "bundling"?

Offer/Answer model is used to verify peers support, resolutions, bandwidth and UDP ports.

P.S: (fora do tópico)

Apenas fazendo uma suposição falsa; digamos que você're um cara do Google ou Facebook; e você're capturando endereços ip do visitante (e é uma verdade universal que todas essas empresas capturam/registram endereços ip do usuário/visitante); então é realmente fácil para você obter portas UDP do usuário alvo; e configurar conexão de dados para transmitir snapshots da atividade do usuário alvo'em tempo real! Tanto o html2canvas como as portas de dados funcionam de forma ininterrupta e os navegadores não't exibem qualquer notificação ou sinal sobre o streaming de dados.