A comunicação em tempo real da Web (WebRTC) é uma nova tecnologia baseada em navegador muito popular nos últimos anos.Muitos fabricantes de VoIP e fabricantes de integração de aplicativos têm gradualmente apoiado a tecnologia WebRTC em suas soluções. A tecnologia WebRTC realiza funções de vídeo e voz aplicando-as a navegadores ou terminais móveis e combinando-as com interfaces API. É claro que o WebRTC tem recebido muita atenção e é inseparável do forte apoio de grandes fabricantes como Google, Microsoft e Mozilla, os principais promotores, bem como da assistência de várias organizações de protocolo bem conhecidas. , como W3C e IETF.
Embora existam muitos artigos sobre WebRTC na Internet, esses artigos apresentam o WebRTC detalhadamente de diferentes ângulos. O site oficial do WebRTC também publica muitos documentos. No entanto, muitos artigos online estão dispersos e discutem sob diferentes ângulos. Além disso, muitos documentos oficiais e livros em papel são publicados basicamente em inglês. Se as habilidades de leitura em inglês de alguns leitores não forem tão altas, isso poderá afetar sua digestão e absorção de tecnologia. A fim de fornecer aos leitores chineses um resumo mais abrangente e completo da tecnologia e aplicações WebRTC, o autor espera fazer uma introdução comparativa e sistemática à tecnologia WebRTC através de um comprimento completo.O conteúdo inclui conhecimento prévio de WebRTC, streaming de mídia e pilhas de protocolos relacionadas. , processamento NAT, configurações de segurança e furtividade, problemas atuais e melhorias futuras do WebRTC, cenários de uso do usuário WebRTC e servidores de mídia WebRTC de código aberto e videoconferência, ferramentas de teste WebRTC e outros pontos de conhecimento, para que leitores comuns possam passar por um Este artigo tem uma ideia muito clara sobre a tecnologia WebRTC e fornece uma base eficaz para o aprendizado adicional da tecnologia WebRTC.Os leitores podem entrar rapidamente no verdadeiro desenvolvimento de aplicativos da tecnologia WebRTC. Em onze capítulos, o autor fará uma introdução completa baseada na arquitetura da tecnologia WebRTC e aplicações relacionadas.
1.Introdução à formação técnica do WebRTC
Primeiro, vamos entender brevemente o conhecimento básico da comunicação. Se olharmos para o desenvolvimento de protocolos de comunicação e voz em tempo real, o primeiro protocolo de comunicação de voz deveria ter ocorrido em 1977. As pessoas aplicaram tecnologia de comunicação em tempo real na rede por meio do Network Voice Protocol (NVP-rfc741) e demonstraram a usabilidade de sua tecnologia. No processo de desenvolvimento da voz, a comunicação em tempo real também passou por vários estágios históricos e gradualmente alcançou avanços em combinação com outras tecnologias. A seguir está uma etapa parcial do processo de desenvolvimento da tecnologia de voz.
Como mostrado no exemplo abaixo, o modelo de trabalho inicial era relativamente simples: com a melhoria contínua da tecnologia e a modificação dos protocolos, a tecnologia de voz atual fez grandes avanços. Para especificações específicas do NVP, os leitores podem verificar o rfc741 para obter detalhes.
Ao falar sobre tecnologia de comunicação em tempo real ou tecnologia WebRTC, gostaríamos também de apresentar brevemente o protocolo de transmissão em tempo real RTP, que foi usado pela primeira vez por volta de 1992 e lançado como padrão em 1996. Atualmente o RTP faz parte do VoIP, SIP ou WebRTC.
Além do protocolo RTP, os protocolos H323 e SIP também são conhecimentos básicos que precisam ser apresentados antes de discutirmos o WebRTC. O H323 foi lançado pela ITU em 1996 e o SIP foi lançado pela IETF em 1999. No campo da voz e do vídeo nas últimas décadas, estes dois protocolos têm desempenhado um papel muito importante na tecnologia de voz e vídeo. É claro que o protocolo SIP agora é reconhecido pelos usuários e pelo mercado, e os usuários do H323 estão diminuindo gradualmente.
O WebRTC é popular por vários motivos, que apresentaremos nos capítulos seguintes. O principal motivo é a facilidade de uso, podendo emprestar outros dispositivos de mídia do navegador do usuário atual, como microfones e câmeras, e acessar diretamente esses recursos de rede por meio da interface API do navegador. Os usuários não precisam instalar e baixar outros plug-ins -ins para obter acesso ao suporte de recursos de rede. O WebRTC também pode alcançar interação de rede ponto a ponto e evitar problemas de acesso à rede com servidores remotos. Especialmente no ambiente de rede VoLTE, a voz pode ser realizada através do canal de dados, o que facilitará muito a comunicação de voz e vídeo do usuário final. Além disso, muitos jogos online agora também podem exibir cenas de jogos através do navegador, e os usuários podem interagir com colegas e amigos ao mesmo tempo por meio de voz, dados e vídeo.
Agora, vamos apresentar brevemente a implementação funcional do WebRTC. As funções do WebRTC incluem os módulos principais e interfaces API acima. O navegador do usuário faz chamadas através de interfaces com HTML, outras linguagens de script e clientes. Preste atenção especial à função RTC do navegador, que inclui codificação de transmissão, processamento de eco e outras funções. Outros dados de mídia podem ser comunicados ao WebRTC por meio da função RTC.
Existem muitos motivos pelos quais o WebRTC é reconhecido pelo mercado. Inclui principalmente os seguintes motivos:
Independente de plataforma e dispositivo. Os desenvolvedores podem desenvolver vários aplicativos baseados em WebRTC por meio de navegadores que suportam WebRTC sem se preocupar com problemas de compatibilidade nos níveis de terminal e sistema operacional. Além disso, o WebRTC também fornece uma API padrão (W3C) e seu suporte de protocolo padrão (IETF) para evitar problemas de compatibilidade de plataforma.
Processamento de segurança de voz e vídeo, o WebRTC criptografa voz e vídeo por meio de SRTP. Os usuários que usam um navegador para fazer login e acessar voz e vídeo exigem configurações relativamente seguras, que atendam aos requisitos de segurança do cenário do usuário (por exemplo, voz e vídeo em um ambiente Wi-Fi inseguro), e outros não podem monitorá-los.
Suporta processamento avançado de linguagem e vídeo, WebRTC suporta a codificação mais recente, voz suporta Opus e vídeo suporta VP8. A codificação integrada elimina os riscos de segurança de downloads de terceiros e pode suportar o ajuste do ambiente de rede para obter melhor qualidade de voz ou vídeo.
Apoiando a criação de transmissão confiável, o WebRTC fornece um método de transmissão confiável, incluindo a estabilidade da transmissão que ainda pode ser alcançada em um ambiente NAT.
Suportando processamento de fluxo multimídia, o WebRTC fornece a agregação de recursos multimídia e múltiplos, e fornece a expansão de RTP e SDP.
Suporta ajuste de diferentes ambientes de rede. Como o WebRTC é executado na plataforma de rede, é muito sensível ao ambiente de rede e à largura de banda. Ele pode detectar e ajustar o ambiente de rede e os requisitos de largura de banda por si só para evitar o congestionamento da rede. Garante esta funcionalidade através de RTCP e SAVPF.
Possui boa compatibilidade com voz e vídeo VoIP. WebRTC implementa operações de compatibilidade com outras mídias, incluindo docking SIP, Jingle e XMPP. Ao mesmo tempo, se precisar fazer interface com outros protocolos tradicionais, você pode usar o gateway WebRTC para obter compatibilidade suave e garantir compatibilidade com protocolos tradicionais.
O uso do WebRTC traz os seguintes benefícios para desenvolvedores e usuários:
Os desenvolvedores podem obter uma integração perfeita sem se preocupar com a compatibilidade da plataforma.
Os desenvolvedores podem usar interfaces API simples para implementar o desenvolvimento de aplicativos.
Os desenvolvedores não precisam se preocupar com problemas causados pelo NAT.
Os desenvolvedores podem usar recursos de codificação mais avançados sem incorrer em taxas de licença comercial.
Os usuários podem usá-lo sem instalação.
Todas as comunicações do usuário são criptografadas.
Os usuários podem obter uma transmissão confiável.
Os usuários podem usar voz e vídeo HD.
Os usuários podem escolher métodos de comunicação mais em tempo real.
A seguir, apresentamos brevemente o famoso exemplo de topologia triangular do WebRTC:
O exemplo acima é um diagrama de processo de inscrição muito comum. Os usuários podem acessar o site oficial para obter outras instruções para o seu processo. Em particular, no ambiente de comunicação de voz, muitos utilizadores podem estar preocupados sobre como implementar a agregação de rede com SIP e PSTN. Vamos listar mais alguns exemplos de soluções de integração relacionadas ao ambiente de voz.
Se o WebRTC implementar chamadas PSTN, ele passará pela conversão de gateway SIP/PSTN e poderá suportar métodos de acesso FXO/FXS ou E1.
Se alguns IPPBX (versões mais antigas do IPPBX) não suportam WebRTC, ou para evitar problemas causados pelo encaixe WebRTC, você também pode encaixar SIP/IPPBX tradicional através do gateway WebRTC e, em seguida, implementar a aplicação de IPPBX + gateway WebRTC + navegador WebRTC Cenas de aplicação. O autor usou o FreePBX-2.5 combinado com o gateway portSIP WebRTC para implementar um caso há dois anos.
No exemplo acima, o IPPBX usa o IPPBX corporativo de código aberto FreePBX. O acesso PSTN pode ser obtido usando uma placa de voz ou gateway de voz PSTN ou gateway sem fio, e a conexão com o terminal do navegador é obtida através do gateway WebRTC portsip. Devido aos requisitos do cliente, a parte de acesso usou a implementação do gateway sem fio da Dingxin Tongda e usou um cartão SIM para fazer chamadas diretas.
2. Processamento de fluxo de mídia WebRTC
Em um ambiente WebRTC, cada terminal é diferente e possui seu próprio método de acesso. Os exemplos a seguir ilustram o processo de processamento de fluxo de mídia WebRTC em vários terminais. Alguns terminais podem estar em um ambiente de rede doméstica, alguns terminais podem estar em um ambiente de intranet corporativa e alguns terminais podem usar wi-fi para acessar a Internet em um café. O servidor de aplicativos está em um ambiente de rede pública.
Se estiver em um ambiente de rede normal, sem WebRTC, a comunicação entre os dois terminais só pode ser roteada e trocada através do servidor de páginas. Porém, se houver problemas de estabilidade da rede ou se a distância entre o servidor e o terminal for relativamente longa, será difícil garantir a comunicação em tempo real entre os terminais.
Se o navegador suportar WebRTC, o roteamento entre dois terminais pode ser realizado sem passar pelo servidor. Ao mesmo tempo, o problema do NAT pode ser resolvido. A comunicação ponto a ponto pode ser alcançada diretamente entre os terminais, garantindo assim a estabilidade do real comunicação em tempo real.
Na introdução acima, discutimos a questão do NAT no WebRTC. Em relação à questão do NAT, já a mencionamos muitas vezes em muitos capítulos anteriores, por isso não explicaremos muito o NAT aqui. Hoje, nos concentramos nas questões de NAT no WebRTC. O mecanismo de política integrado do WebRTC (Estabelecimento de Conectividade Interativa) é usado para resolver o problema do NAT. Na comunicação ponto a ponto, o ICE consegue comunicação ponto a ponto fazendo furos. Aqui, o objetivo principal do ICE é encontrar o melhor caminho para conexão entre dois terminais através do trânsito entre diferentes servidores. Na maioria dos casos, o ICE pode alcançar intercomunicação ponto a ponto usando STUN. Às vezes, também precisa ser encaminhado através de um servidor TURN. A detecção e emparelhamento de pares do ICE requer seis etapas. O rfc5245 tem a seguinte definição para detecção de ICE:
1. Classifique os pares candidatos em ordem de prioridade.
2. Envie cheques para cada par de candidatos em ordem de prioridade.
3. Confirme os cheques recebidos do outro agente.
Na quinta etapa, o navegador precisa verificar os dados do STUN ao mesmo tempo. Como mostrado abaixo:
O processo de consulta do servidor STUN é o seguinte:
Quando o servidor STUN não consegue consultar dois terminais, ele precisa usar o servidor TURN para conseguir isso. Os leitores devem observar aqui que as estratégias utilizadas podem ser diferentes em diferentes cenários de NAT. Descrevemos aqui apenas o cenário de NAT simétrico.
A seguir está uma comparação simples entre usuários que usam STUN e TURN para ajudar os leitores a compreender mais claramente a função e os custos de implantação desses dois servidores. Em relação ao uso de ICE e atributos de parâmetros específicos, o autor fará uma introdução muito detalhada nos capítulos subsequentes. Os usuários também podem consultar documentos históricos para maior aprendizado. O autor aqui me lembra novamente que durante o processo de chamada WebRTC, a maioria das falhas de chamada se deve a problemas de negociação do ICE.As seis etapas acima precisam de atenção especial na solução de problemas.
3.Protocolos relacionados ao WebRTC
WebRTC suporta muitos padrões RFC.Essas organizações concluíram a elaboração de padrões, definições de API e alguns protocolos de extensão relacionados para WebRTC. Entre elas, três organizações exigem atenção dos leitores: IETF, W3C e RTCWEB. Todos eles têm seus próprios sites oficiais que os leitores podem conferir. As pilhas de protocolos usadas pela tecnologia WebRTC incluem o seguinte: os leitores só podem se concentrar na camada de aplicação e na camada de transporte. Esses protocolos têm suas próprias definições de especificações na RFC. O mais importante é a especificação ICE. Para a especificação ICE, os usuários podem verificar rfc5245.
Devido ao desenvolvimento contínuo das comunicações convergentes, a interoperabilidade entre WebRTC e SIP tornou-se muito importante e, nas comunicações convergentes empresariais, é necessário aceder às funções de PSTM ou UC empresarial. Portanto, passaremos mais tempo discutindo o relacionamento e as aplicações entre WebRTC e SIP.
4. Rascunhos relacionados ao WebRTC
O desenvolvimento de qualquer tecnologia é indissociável da promoção de algumas organizações, que concluíram a padronização das especificações técnicas. No capítulo acima, mencionamos o grupo de trabalho RTCWEB, que está elaborando alguns novos rascunhos sobre algumas funções do WEBRTC e ainda não formou uma especificação RFC formal. Esses rascunhos são:
Real Time Protocols for Browser-based Applications Web Real-Time Communication Use-cases and Requirements Web Real-Time Communication (WebRTC): Media Transport and Use of RTP WebRTC Security Architecture Security Considerations for WebRTC WebRTC Data Channels WebRTC Data Channel Establishment Protocol JavaScript Session Establishment Protocol WebRTC Audio Codec and Processing Requirements STUN Usage for Consent Freshness Transports for RTCWEB
Além dos rascunhos acima, a RTCWEB também cooperou com outras organizações para escrever outros padrões de protocolo. Atualmente, esses padrões incluem:
MMUSIC, este rascunho define a extensão SDP e o suporte à extensão ICE.
AVTCORE, este rascunho define o suporte à extensão RTP.
RMCAT, este rascunho define o suporte ao controle de congestionamento RTP.
TRAM, este projeto define suporte estendido para STUN e TURN.
No rascunho do RTCWEB, uma variedade de cenários de usuário e suas definições são listados, incluindo cenários de usuário de navegador para navegador e cenários de usuário de teste de navegador para rede:
Simple Video Communication Service
Simple Video Communication Service, NAT/Firewall that blocks UDP
Simple Video Communication Service, Firewall that
only allows traffic via a HTTP Proxy
Simple Video Communication Service, global service provider
Simple Video Communication Service, enterprise aspects
Simple Video Communication Service, access change
Simple Video Communication Service, QoS
Simple Video Communication Service with screen sharing
Simple Video Communication Service with file exchange
Hockey Game Viewer
Multiparty video communication
Multiparty on-line game with voice communication
Telephony terminal
Fedex Call
Video conferencing system with central server
5. Função de expansão da pilha de protocolo de mídia WebRTC
Neste capítulo, apresentaremos vários conceitos-chave na função de expansão do protocolo de mídia do WebRTC. Primeiro, vamos apresentar o primeiro conceito importante, cabeçalho RTP.
No cabeçalho, todos precisam ficar atentos às partes marcadas em vermelho e aos valores relacionados. Por exemplo, Sequence Num detecta números de sequência incorretos. Se um número incorreto ou excedido for detectado, ocorreu um erro. Se a reprodução da voz não for suave ou coerente, o carimbo de data/hora poderá estar fora de sincronia ou poderá ocorrer um erro. SSRC é usado para confirmar os dados enviados ao pacote. Se o pacote for perdido, o CC será contado cumulativamente. Com relação à estrutura de sintaxe específica do cabeçalho RTP, os usuários podem consultar o rfc para um estudo mais aprofundado.
RTCP é outro conceito de protocolo importante. RTCP é um protocolo que controla e gerencia cada sessão de mídia RTP. Em muitos casos, a porta RTCP pode ser configurada em SDP (a=).Se não puder ser configurada, o RTCP usa uma porta ímpar superior à porta RTP (porta RTP + 1). Por exemplo, se a porta RTP for 7000, o RTCP usará a porta 7001.
Aqui, RTP e RTCP vincularão suas sessões de mídia correspondentes, e ambas as partes que geram dados enviam dados com qualidade de voz através do RTCP. CNMAE inclui os dados do remetente. É claro que o tamanho dos pacotes RTCP também é limitado, geralmente limitado a 5% do tamanho do pacote RTP. Cada perfil RTP define a frequência de envio RTCP, o tempo de envio e os requisitos da regra de envio RTCP. Através dessas configurações de política, o RTP pode garantir que, dentro de uma determinada largura de banda da rede, os recursos da rede não serão consumidos em demasia.
O RTP usa perfis para negociar a comunicação entre as duas partes, e o WebRTC usa um perfil expandido para suportar a negociação do WebRTC e o processamento do mecanismo RTCP. A seguir está um exemplo simples para ilustrar a negociação de dados do WebRTC.
Na introdução acima, em cada fluxo de mídia real, o RTP e o RTCP usam portas diferentes para lidar com seus próprios serviços. No entanto, às vezes os usuários podem encontrar essas coisas. Não há problema com a transmissão mútua entre as portas RTP, mas pode haver um problema com a porta RTCP. No WebRTC, para evitar o problema mencionado, o WebRTC utiliza um método de multiplexação (rtcp mux), que utiliza uma porta para compartilhar as portas de RTP e RTCP, reduzindo o número de portas ocupadas. Claro, isso pode causar problemas de conexão entre chamadas WebRTC e chamadas SIP. Os usuários podem precisar verificar as configurações do lado do navegador ou do lado do servidor em cenários de uso reais. Por exemplo, na plataforma Asterisk, pjsip suporta rtcp_mux=yes para suportar negociação de porta WebRTC.
O impacto da multiplexação no WebRTC também é muito óbvio. Normalmente, voz e vídeo são enviados entre si por meio de portas RTP diferentes. No ambiente WebRTC, o WebRTC usa tecnologia de multiplexação para enviar todos os fluxos de mídia por meio de uma porta RTP. Pode ter outros efeitos.
As vantagens e desvantagens da maneira como o WebRTC usa uma única porta RTP para lidar com mídia são muito óbvias, conforme mostrado em:
Reduziu o número de candidatos ICE coletados
Tempo de execução do ICE reduzido
Como há menos sessões, a chance de falha na sessão é reduzida.
Isso pode aumentar a dificuldade de garantia de QoS, pois o receptor também precisa lidar de forma diferente com o SSRC e a carga útil de sua voz e vídeo.
A seguir, vamos discutir as questões sobre RTP e NAT no WebRTC. Como todos sabemos, o RTP não utiliza diretamente o seu próprio RTP, necessita de UDP para transmissão. Mas as portas UDP são todas dinâmicas. Para reduzir o mapeamento de portas NAT, o WebRTC requer o uso de RTP Simétrico e RTCP Simétrico, o que facilita a solução de problemas de NAT. O RTP simétrico exige que tanto o envio quanto o recebimento usem a mesma porta RTP. Para especificações específicas, você pode consultar o Capítulo 3 do rfc4961. Este capítulo define as duas portas.
O congestionamento do fluxo de mídia também é um problema muito grande, que afeta diretamente a qualidade dos fluxos de mídia. Como todos sabemos, o congestionamento pode ser tratado no TCP, mas o UDP não suporta tal mecanismo. Se o UDP não oferecer suporte, o RTP não poderá suportar o mecanismo de tratamento de congestionamento. Entretanto, o RTCP pode monitorar e realimentar seu congestionamento, resolvendo assim o problema de suporte do mecanismo de congestionamento RTP. Se for uma chamada de videoconferência, a largura de banda é uma questão mais sensível.Na troca de dados RTCP, se ocorrer congestionamento na rede, o remetente pode reduzir a largura de banda para evitar congestionamento. Isso é tratado por meio de um mecanismo semelhante no WebRTC:
Disjuntor, se ocorrer congestionamento na rede, o RTP deverá parar de enviar pacotes de dados. Estratégias de configuração específicas podem ser implementadas através do perfil RTP/AVP.
O método RMCAT depende do mecanismo TRFC do TCP.
6.Sinalização/transmissão/protocolo WebRTC
Neste capítulo, nos concentramos na sinalização, nos métodos de transmissão e nos diversos protocolos usados pelo WebRTC. Agora discutimos brevemente as principais funções da sinalização:
Criação negociada de recursos de mídia
Serviços de assinatura e autenticação em sessão
Controlar sessões de mídia, direcionar o progresso da sessão, modificar ou encerrar processos de sessão
Crie e modifique sessões para ambas as partes simultaneamente
Das quatro funções acima, a primeira é uma função necessária e as outras são funções opcionais. Simplificando, no WebRTC não existe a chamada sinalização padrão e a interação entre o navegador e o servidor é implementada por meio de linguagem de script. Para desenvolvedores WebRTC, o requisito mínimo é suporte HTTP, suporte HTML e WebRTC. O resto depende inteiramente das necessidades do desenvolvedor.
Em um ambiente WebRTC, os navegadores são executados em JavaScript. Qualquer sinalização usada no lado do servidor pode garantir a compatibilidade entre os usuários. No exemplo a seguir, os servidores A, B e C escolhem sinalização diferente para garantir compatibilidade do lado do usuário.
No entanto, alguma sinalização precisa manter um método de interfuncionamento padrão, caso contrário ocorrerão erros de negociação de sessão. Isso exige que o mecanismo de negociação entre os navegadores seja unificado, que a negociação entre os navegadores possa funcionar normalmente e que cada um entenda as capacidades de mídia um do outro. Portanto, não importa qual sinalização seja usada no lado do servidor, para cada sessão entre terminais, a codificação, a mídia e os resultados de configuração devem ser padrão, o ICE deve ser interoperável e as chaves SRTP devem ser interoperáveis. Entre os métodos de transmissão de sinalização, o WebRTC suporta três métodos de transmissão de sinalização: WebSocket, HTTP e Canal de Dados.
Na ilustração acima, o servidor usa WebSocket para transmissão de sinalização. Na verdade, o WebSocket é acessado em um novo método HTTP. O navegador atualiza a solicitação. Nessa nova solicitação, a conexão HTTP é convertida em um acesso WebSocket. Observe aqui que o protocolo WebSocket é definido pelo IETF, mas a API WebSocket é definida pelo W3C. Além disso, dois navegadores não podem abrir diretamente um WebSocket para acessar um ao outro.
A sinalização WebRTC também pode ser transmitida via HTTP. Cada navegador envia dados ao servidor por meio de uma solicitação XML HTTP. HTTP usa GET ou POST para enviar dados de mensagens de sinalização ao servidor web.
Depois que a sinalização inicial via WebSocket ou HTTP for estabelecida com sucesso, o canal de dados será criado com sucesso e a interação de mídia ponto a ponto será iniciada. O canal de dados transportará sinalização de voz e vídeo. Como a sinalização de voz e vídeo são comunicações ponto a ponto por meio de canais de dados criptografados, a segurança também é bastante aprimorada.
Acima mencionamos a questão da interação de sinalização HTTP. Usamos o exemplo a seguir para ilustrar como implementar a interação simples de mídia SDP por meio do pooling HTTP:
A ilustração a seguir ilustra a interação do Pooling HTTP entre servidores independentes do servidor Web e o servidor de sinalização:
A ilustração a seguir demonstra como usar o WebSocket Proxy sem usar Pooling:
No método de transmissão de sinalização WebRTC, também podemos usar SIP para transmissão interativa. A negociação de mídia SDP aqui usa rfc3264. Tanto os terminais de navegador quanto os terminais SIP podem ser interconectados.
Para ambientes de voz SIP, WebSocket é um novo método de transmissão ao executar WebRTC. Muitos softphones de terminais SIP agora são implementados através de JavaScript. O script pode ser baixado para o navegador e suporta a API SIP do navegador, o navegador abre a porta através do WebSocket para implementar o registro SIP e implementa a transmissão criptografada do WebSocket através do WSS. O exemplo a seguir demonstra um mecanismo de processo SIP em WebRTC (incluindo registro e chamada de terminal SIP):
As soluções de comunicação de voz de código aberto estão se tornando cada vez mais populares entre os usuários. Aqui listamos vários projetos populares de código aberto, incluindo servidores de mídia e produtos de terminal SIP, para que você possa testar suas funções. Para esclarecer, o FreeSWITCH está faltando na lista.
Jingle é uma extensão do XMPP, o cliente suporta JavaScript e também suporta transmissão de sinalização WebSocket. Como o Jingle é uma extensão do XMPP, o servidor de sinalização aqui ainda é o servidor XPMM.
Através da nossa introdução acima, explicamos aproximadamente o processo de vários métodos de transmissão. A ilustração a seguir resume os prós e os contras de vários métodos:
JSEP (Javascript Sessionestablishment Protocol) é usado no WebRTC para definir a negociação de sessões de mídia e a negociação de canais de DADOS. Ele ainda usa entidades de objeto SDP como descrição de sessão e protocolo de negociação de oferta/resposta. Deve-se observar que o JSEP não configura nenhum modo de sinalização especial ou modo de máquina de estado, mas fornece um mecanismo para criar ofertas e respostas e aplicá-las na sessão. Portanto, o terminal do navegador precisa analisar sozinho os dados que envia.
A seguir está uma ilustração da máquina de estado do JSEP. O JSEP fornece seis estados da máquina de estado. Os usuários podem acessar a especificação JSEP para pesquisas adicionais.
A extensão SDP do WebRTC suporta três funções relativamente novas, que são BUNDLE, MSID e CNAME arbitrário. Os usuários podem conferir no site oficial.
A seguir, vamos dar uma olhada no fluxo de processamento do ICE. De acordo com a introdução do capítulo acima, a detecção do ICE requer cinco etapas (se o endereço IP de uma das duas partes mudar, o ICE precisa ser reiniciado, portanto também pode ser considerado como seis etapas).
7.WebRTC NAT e ICE
WebRTC oferece suporte ao mecanismo de processamento NAT. No WebRTC, o ICE é usado para oferecer suporte ao processamento NAT. Já fizemos uma breve introdução, o ICE requer o suporte dos servidores STUN e TURN. Quanto ao uso de NAT e STUN, o autor discutiu isso nos documentos históricos, aos quais os usuários podem consultar.
O nome completo em inglês do ICE é Estabelecimento de Conectividade Interativa. RFC5245 (RFC6336 atualizado) especifica ICE. A definição geral simples é: ICE=STUN+TURN+mecanismo de negociação+caminho de negociação. A arquitetura do ICE está representada na legenda abaixo.
A seguir está uma estrutura de mensagem candidata. Para saber o significado de cada parâmetro na estrutura, consulte a Parte 3 (Terminologia) da RFC3245.
Nos capítulos anteriores, o autor explicou brevemente as seis etapas da criação do ICE usando muitas ilustrações. Vamos enfatizar isso em detalhes novamente. As seis etapas executadas pelo ICE são:
Descubra e colete informações do terminal do aplicativo. Colete o endereço de comunicação do terminal e o tipo de terminal solicitante (host, reflexivo e candidato a relé). Estes quatro endereços representam respectivamente o endereço de rede interno do chamador, o endereço de rede pública do chamador, o endereço de rede pública do chamador e o endereço de retransmissão.
Abaixo está um exemplo de um SDP representando três endereços IP diferentes.
Os candidatos são processados de acordo com a prioridade. Na maioria dos casos, os candidatos do Relay são usados primeiro.
Analise as informações do candidato e envie-as ao par candidato
Pareie os candidatos para garantir que ambas as partes correspondam
Verifique a conectividade do candidato emparelhado
Verifique se o ICE consegue se conectar com sucesso e, se for bem-sucedido, envie uma mensagem de confirmação
Nas etapas acima, o autor primeiro introduz alguns conceitos e conteúdos importantes nas etapas de execução e, em seguida, conduz análises detalhadas com base em cenários específicos. Nas etapas acima, o servidor STUN primeiro precisa obter o endereço candidato. Com relação aos detalhes específicos do STUN, os leitores podem obter materiais de aprendizagem em outros sites confiáveis.
Além do STUN, o ICE usa o servidor de extensão TURN do STURN para obter um endereço de retransmissão.
O processo específico de chamada TURN inclui as seguintes etapas: início da criação de uma conexão, interoperação de mídia após a criação da conexão, atualização regular da configuração de tempo limite e encerramento da sessão.
Tanto STUN quanto TURN possuem seu próprio método, configurações de atributos, configurações de segurança, gerenciamento de códigos de erro e outras especificações detalhadas. Os usuários podem consultar documentos históricos para estudos mais aprofundados, que não serão apresentados aqui.
Após obter o endereço através de STUN e TURN, o ICE precisa iniciar a troca SDP. Na troca SDP, os leitores precisam prestar atenção às suas configurações de segurança, como configurações de senha e vários endereços de parâmetros principais:
Em particular, na ilustração acima, o usuário usa ice-ufrag e ice-pwd para realizar autenticação de segurança no STUN. Essas duas senhas são senhas arbitrárias geradas automaticamente, com no mínimo quatro caracteres para o nome de usuário e no mínimo 22 caracteres para a senha. Vários parâmetros principais do SDP são usados para implementar a negociação e troca de SDP. Explicaremos em detalhes na próxima seção.
Após o ICE obter as mensagens SDP de ambas as partes, ele precisa realizar uma verificação de emparelhamento. O ICE verifica se eles têm o mesmo ID de componente. Após o emparelhamento, ele combina a parte chamadora e a parte chamada para gerar um emparelhamento Foundation. O emparelhamento da Fundação é gerado pela combinação da Fundação local e da Fundação remota. Por favor, preste atenção à mudança de a=candidate. Se a Fundação local for 1, a Fundação remota recebida será 2. Finalmente, a Fundação emparelhada será 1 2.
Durante a inspeção do ICE, ambos os terminais precisam informar à outra parte quem é a parte controladora e a parte controlada. Quando a inspeção ICE começar oficialmente, cada grupo de pares candidatos entrará em cinco inspeções de status, dependendo do status real:
Congelado, a verificação ainda não começou
Esperando, estado de espera, ainda não executado
Em andamento, em estado de processamento
Bem-sucedido/Falha, a verificação foi concluída e está em estado de sucesso ou o dispositivo foi verificado e está em estado de falha.
Após a verificação do candidato ser concluída, o controlador ICE ainda pode notificar a parte controlada pelo ICE para alterar o par candidato para suportar o envio de mídia através do parâmetro de atributo USE-Candidate. A parte controlada pelo ICE responde com USE-Candidate para confirmar esta modificação de emparelhamento.
Após a conclusão da verificação do ICE, para manter o estado ativo, ambas as partes precisam enviar mensagens de atualização por meio de Keepalives para garantir que a conexão esteja normal e que o mapeamento NAT não expire e outros problemas. Este período de tempo é de 15 segundos.
No atual padrão de protocolo ICE, um problema relativamente embaraçoso é o processamento de mensagens de resposta do terminal. STURN enviará uma mensagem de resposta, mas o terminal não processará a mensagem de resposta. Esta também é uma função que atualmente requer suporte adicional do protocolo de extensão ICE. Por exemplo, se nenhuma mensagem de resposta for recebida, o ICE precisa reiniciar; se uma mensagem de resposta for recebida, como proceder com a próxima etapa do processamento da resposta processo. Em relação ao processamento de mensagens de resposta ICE, os leitores podem consultar (draft-muthu-behave-consent-freshness-01).
Quando ambos os terminais estiverem em execução, se o ICE descobrir que o endereço de um dos candidatos mudou, o ICE irá reiniciar o ICE e emparelhar novamente. O texto acima é uma breve introdução sobre a criação, verificação, emparelhamento e atualização de tempo do ICE. Para explicar o processo de negociação ICE com mais detalhes, ilustramos estas etapas específicas através de um processo SIP/ICE:
Através do pedido de prioridade, combine os dois pares para verificar o ICE e iniciar o teste. Se ambas as partes testarem com sucesso, a próxima etapa da interação de sinalização será realizada, por exemplo, o SIP 2 envia uma mensagem 180 e uma mensagem 200 OK. Se a mensagem inicial enviada for inconsistente com a mensagem recebida, o Telefone SIP 1 precisará reenviar a mensagem Re-INVITE, realizar a verificação de teste e, finalmente, receber uma mensagem 200 OK.
Após o teste ICE ser bem-sucedido, ambas as partes começam a enviar voz RTP.
Com relação ao suporte de ICE, em muitos de nossos ambientes comuns, alguns terminais SIP podem suportar ICE, mas alguns terminais podem não suportá-lo. Os usuários podem verificar os recursos de configuração ICE de vários softphones. A seguinte mensagem SIP indica que o terminal suporta ICE: sip.ice.
Se o terminal peer não suportar ICE, o terminal terá apenas duas opções: 1) Continuar a conexão sem usar ICE. O ICE suporta um mecanismo de retorno de detecção automática para notificar o peer de que não suporta ICE. 2) Ou continuar a usar o ICE com suporte de autorização opcional. De acordo com as disposições do Mandating Support no RFC5768, o terminal SIP pode adicionar uma opção de gelo no Require da solicitação INVITE.
Além disso, às vezes os usuários podem ver exemplos em que não há sip.ice no cabeçalho SIP INVITE do terminal, mas há de fato informações de candidato ICE no SDP. Isso também é resultado de incompatibilidade mútua, mas no final é uma incompatibilidade. Suporta o logotipo ICE.
Devido ao rápido desenvolvimento da própria tecnologia SIP, a versão do ICE é constantemente atualizada. Apresentamos brevemente duas versões "atualizadas" do ICE. Aqui, o que chamo de versões atualizadas são apenas uma otimização do ICE, não são uma atualização ou atualização do próprio ICE:
A principal função do ICE-lite é simplificar a complexidade do ICE, por exemplo, vimos o SBC.
O principal objetivo do Trickle ICE é diminuir o tempo de processamento de negociação do ICE e evitar a redistribuição dos candidatos encaminhados, podendo ser ativado se necessário. Ao contrário do fluxo de processamento padrão do ICE, que precisa coletar informações sobre o status das informações do candidato, ele verifica o status da conexão com o candidato host no início e processa outros mecanismos de troca em paralelo. Portanto, Trickle ICE reduz relativamente o tempo de processamento.
8. Segurança e privacidade WebRTC
Questões de segurança e privacidade são tópicos muito importantes nas comunicações pela Internet. No WebRTC, os aspectos de segurança envolvem muitas tecnologias. É claro que, ao usar navegadores, muitos fabricantes fornecem alguns mecanismos de segurança, e os indivíduos também devem ter um certo grau de conscientização sobre segurança. Não perderemos tempo apresentando-os aqui. No WebRTC, os dois recursos terminais mais importantes são a câmera e o microfone. Portanto, os usuários precisam de certas configurações de segurança ou permissões para proteger esses recursos de mídia. O uso do WebRTC exige que os navegadores suportem mais protocolos e mais configurações do lado do servidor, o que inevitavelmente trará mais riscos de segurança e possibilidade de serem atacados. Abaixo, o autor lista diversas sugestões relacionadas à segurança às quais os leitores devem prestar atenção:
Os invasores podem usar WebRTC para atacar por meio da interface da API JavaScript.
Os usuários de navegadores podem precisar atualizar seus navegadores com frequência para evitar ataques.
A sinalização do WebRTC também pode ser atacada, tudo depende da sinalização e da porta utilizada. Por exemplo, se WebSocket e SIP forem usados, os invasores poderão atacar através das configurações de segurança dessas interfaces.
A mídia WebRTC pode ser atacada, por exemplo, seja monitorada ou gravada.
O SRTP não pode criptografar o cabeçalho RTP, portanto a mídia entre os dois navegadores ainda pode não ser segura.
Embora o SRTP ainda tenha certas limitações, o SRTP ainda é o principal protocolo de segurança no WebRTC. Agora, vamos dar uma olhada no fluxo de processamento SRTP, que passa principalmente pelas quatro etapas a seguir.
Entre esses quatro processos, já foram introduzidas as etapas 1 e 2. Aqui nos concentramos nas etapas 3 e 4. Durante o processo de autenticação de segurança do DTLS, ele usa o protocolo cliente/servidor para processamento. Ele pode usar certificados CA e certificados autoautorizados para verificação de certificados. Como o DTLS é um método de trabalho cliente/servidor, uma extremidade do navegador deve ser o cliente e a outra extremidade deve ser o servidor. No WebRTC, ambos os navegadores devem escolher suas funções. A seleção da função é definida na mensagem SDP (a=setup), a Oferta contém a=setup:actpass e a Resposta pode conter a=setup:active ou passiva.
O TLS usa X.509, que é um certificado emitido por uma CA, mas os navegadores geralmente não possuem esses certificados. DTLS-SRTP pode usar certificados gerados por chave pública/privada.
Existem muitos cenários de uso do WebRTC. O que mais nos preocupa aqui são as questões de segurança no ambiente de escritório corporativo. Portanto, para usuários corporativos, os seguintes aspectos precisam ser considerados ao implantar o WebRTC:
Riscos de segurança causados por configurações de firewall de rede corporativa, configurações de acesso ACL e problemas de fluxo de dados ponto a ponto
As gravações de áudio e vídeo entre navegadores, os logs do sistema e a formulação de políticas de segurança corporativa afetam a implantação do WebRTC?
Pode ser perfeitamente integrado à rede empresarial atual?
9. Cenários de uso do WebRTC
Existem muitos cenários de uso para WebRTC. Como o WebRTC é uma tecnologia relativamente nova, ainda pode haver muitos novos cenários de aplicativos emergentes. Os cenários de uso atuais são divididos aproximadamente em duas partes: uma é o cenário de uso do WebRTC no estado de comunicação e a outra é o cenário de uso do WebRTC no estado de não comunicação. Os cenários de uso do WebRTC na comunicação incluem o seguinte:
Conferência por telefone/videoconferência baseada em página
Serviços de comunicação com clientes, incluindo comunicações convergentes de UC, comunicação com clientes
Comunicações convergentes empresariais/IPPBX/call center, suporta implementação SIP/HTML e chamadas SIP/PSTN
Métodos de comunicação distribuída/serviços públicos, etc.
Suporte WebRTC móvel, WebRTC não apenas suporta navegadores de desktop, mas também suporta interfaces API nativas Android/IOS
Cenário de aplicativo WebRTC de código simples
Realize outras operações controlando a câmera e o microfone
Telemedicina/Atendimento Domiciliar
Atendimento ao cliente online/suporte no local
Treinamento individual on-line
Transmissão ao vivo da mídia
lar inteligente
Manufaturação industrial
Os cenários de aplicativos WebRTC em estados de não comunicação incluem:
Os aplicativos de jogos incluem bate-papo, compartilhamento de arquivos, etc.
Sobreposição de aplicativo da web
aprendizado de máquina
Internet das Coisas
Compartilhamento de arquivos
jogos de realidade virtual
10. Situação atual e tendências de desenvolvimento do WebRTC
Embora a tecnologia WebRTC tenha atualmente muitos cenários de aplicação, a tecnologia também está se desenvolvendo muito rapidamente. No entanto, sua tecnologia é atualizada muito rapidamente e os leitores precisam verificar frequentemente o site oficial para conhecer desenvolvimentos e tendências tecnológicas.
Alguns dos links mais importantes são os seguintes:
https://www.w3.org/TR/webrtc/ https://w3c.github.io/webrtc-pc/ https://www.w3.org/TR/mediacapture-streams/
Como o WebRTC depende do suporte do navegador, atualmente a maioria dos navegadores suporta funções WebRTC e algumas funções, portanto, os leitores devem verificar o status de suporte desses navegadores para desenvolver seus próprios aplicativos:
Mais navegadores oferecerão suporte a WebRTC no futuro. Embora os aplicativos WebRTC tenham perspectivas muito amplas, eles ainda enfrentam muitos desafios:
Problemas de compatibilidade em diversas plataformas, especialmente compatibilidade de codificação de vídeo
Problemas de implantação padronizada
A migração para plataformas móveis continua escassa
Impacto na vida útil da bateria móvel
Falta de apoio dos padrões governamentais e da indústria
De acordo com os planos oficiais e requisitos do mercado, a tecnologia WebRTC ainda precisa de muito trabalho no futuro, e várias tarefas importantes precisam ser concluídas no futuro próximo:
As versões finais das especificações e protocolos do W3C e IETF são formadas, porque muitas dessas recomendações são rascunhos e precisam ser finalizadas, e será necessário mais tempo para concluí-las no futuro.
Os navegadores precisam oferecer suporte a mais recursos WebRTC e à versão mais recente
A codificação de vídeo é amplamente utilizada em WebRTC, mas precisa ser finalizada
Em aplicativos corporativos, ainda não existem muitos aplicativos WebRTC e mais aplicativos precisam aumentar a proporção de uso do WebRTC.
11. Servidor WebRTC e exemplos de projetos de código aberto
Mencionamos na tecnologia anterior que o WebRTC oferece suporte a muitos cenários de aplicativos. Entre eles, os leitores podem estar mais interessados em algumas soluções para videoconferência. Atualmente, os servidores WebRTC de código aberto são relativamente populares:
Jitsi
atual
Gateway Janus WebRTC
Sopa de mídia
O exemplo a seguir é um exemplo de integração entre Kurento e Asterisk. Os terminais SIP são gerenciados através do Asterisk. Aqui, Kurento é usado como um servidor de mídia WebRTC para implementar a função de mixagem de videoconferência.
Devido ao desenvolvimento do WebRTC, as ferramentas de teste também aumentaram lentamente. Existem muitas ferramentas de teste para WebRTC na Internet. As ferramentas de teste também têm um propósito completamente diferente. Hoje, o autor apresentará a você uma ferramenta de teste de estresse sobre WebRTC (Jattack: uma ferramenta de teste de carga WebRTC).O artigo inclui arquitetura técnica, processo de teste, resultados de teste e principalmente testes e análises de recursos do sistema.
Para métodos de teste específicos e resultados de testes, os leitores podem verificar os links para materiais de referência e realizar pesquisas adicionais através dos artigos do autor. Existem também muitas ferramentas comerciais de teste para WebRTC, que podem detectar o status de execução do WebRTC, testes de estresse e outras funções. Os mais famosos são o testRTC, os leitores podem adquirir ou experimentar sua versão demo.
Devido a problemas de compatibilidade do navegador, muitos aplicativos WebRTC não podem ser implantados com sucesso. Testar a compatibilidade de diferentes navegadores também é uma grande dor de cabeça. O Google lançou uma ferramenta (KITE) para testes de compatibilidade de diferentes navegadores, os leitores podem aprender mais sobre ela. Esta ferramenta também é muito conveniente para testes.
12. Resumo
Na visão geral técnica do WebRTC, o autor forneceu uma introdução relativamente completa e abrangente à tecnologia WebRTC em onze aspectos. Esses capítulos incluem: conhecimento prévio, processo de mídia, organização WebRTC ITEF/W3C, protocolo de sinalização, protocolo de mídia, processo de criação de NAT/ICE, suporte de segurança e privacidade, cenários de usuário WebRTC, partes que precisam ser melhoradas na futura tecnologia WebRTC e também listas Vários problemas precisam ser enfrentados ao implantar o WebRTC. Por fim, o autor fornece aos leitores diversas soluções baseadas em código aberto, soluções de teste WebRTC baseadas em código aberto e ferramentas para testes WebRTC.
O autor faz o possível para fornecer uma introdução relativamente detalhada e abrangente aos principais nós técnicos de cada capítulo. Devido às limitações de espaço, alguns detalhes técnicos relevantes exigem que os leitores façam estudos mais aprofundados por conta própria. Os leitores podem acessar seus recursos de aprendizagem de acordo com estes links de referência. Você também pode aprender sobre os processos dessas tecnologias por meio de especificações RFC e alguns rascunhos.