- Spegnimento
- 26 aprile 2026 alle ore 23:18 UTC
- Autore
- Kamo
- Impegno
- af6f181
Due parti browser-a-browser chiamate connesse allo strato SIP ma non aveva audio o direzione. Voicemail (one-way Asterisk → browser) ha lavorato perché Asterisk simmetric-RTP fallback potrebbe imparare il browser indirizzo da qualsiasi pacchetto in entrata. Il ponteggio di due parti ha bisogno di entrambi i lati RTP per raggiungere effettivamente Asterisk, il che significa che ICE deve convergere su un coppia candidato il browser può andare a. Asterisk aveva ice support=yes per-endpoint ma `STUN indirizzo: 0.0.0.0:0` a livello del motore rtp, quindi il suo unico candidato offerto era il suo ospite (LAN/pod-network) IP — irraggiungibile dai browser Internet pubblici. Configurazione ****************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************** anche pubblicizzare il suo candidato srflx (pubblico). L'indirizzo STUN risolve ora a 74.125.250.129:19302 dopo un carico di modulo fresco. rtp.conf in linea piuttosto che contare su rtp custom.conf perché il rtp motore istantanee la sua configurazione [generale] a tempo di carico del modulo e mai rileggerlo da includere i file (lo stesso gotcha che ha morso il precedente http.conf change). Il rtp additional.conf autogenerato e qualsiasi futuro rtp custom.conf sono ancora ri-inclusi dopo le chiavi in linea per compatibilità in avanti.