- Navios
- 26 de abril de 2026 às 23:18 UTC
- Autor
- Kamo
- Enviar
- af6f181
Chamadas de navegador para navegador bipartidário conectadas na camada SIP, mas não tinham áudio em qualquer direcção. Correio de voz (Asterisco de via única → browser) funcionou porque Asterisco simétrico-RTP fallback poderia aprender o navegador Endereço de qualquer pacote de entrada. A ponte bipartidária precisa de ambos os lados» RTP para realmente atingir o Asterisco, o que significa que a ICE tem de convergir para candidato par o navegador pode rota para. Asterisco tinha ice support=yes por ponto final, mas `STUN address: 0.0.0.0:0` no nível do motor rtp, então seu único candidato oferecido foi seu anfitrião (LAN/pod-network) IP — inacessível a partir de navegadores de internet públicos. Configurar Em rtp.conf para que o Asterisco possa também anuncia seu candidato srflx (público). Endereço STUN agora resolve a 74.125.250.129:19302 após uma nova carga do módulo. Inlined rtp.conf em vez de confiar em rtp custom.conf porque o rtp motor instantâneos sua configuração [geral] no tempo de carregamento do módulo e nunca re- lê a partir de arquivos de inclusão (o mesmo gotcha que mordeu o anterior http.conf alteração). O rtp aditional.conf gerado automaticamente e qualquer futuro rtp custom.conf ainda são re-incluídos após as teclas em linha para compatibilidade com o futuro.