Bueno, en realidad, muchos usuarios del foro al que pertenezco suelen comunicarse en entornos externos, y unirse con el micrófono abierto directamente puede provocar que el ruido ambiental interfiera con la comunicación. Y hay otro error: aunque hagas clic para silenciar el micrófono en la página de voz, el micrófono sigue abierto en realidad, y tienes que desactivarlo y volver a activarlo para cerrarlo de verdad.
En comparación con Jitsi, hay algunas diferencias, ya que Jitsi tiene una interfaz que te permite elegir si silencias o no el micrófono antes de unirte oficialmente al chat de voz, pero Discourse Voice no tiene esto. Creo que esta interfaz evita en gran medida el problema.
Ah, ya veo. ¿Estarían esos usuarios beneficiados por el PTT? Tenemos soporte básico para ello, pero una mejor experiencia con PTT, tanto en móviles como en escritorio, requiere una aplicación nativa, y es un área que estamos explorando activamente.
¿Casualmente tienes alguna otra conjetura? Intenté invitar a otro usuario de demostración y, lamentablemente, sigue sin funcionar. ¿Has logrado invitar usuarios mediante un enlace con éxito?
Actualización: Acabo de enviar una invitación a un administrador para una nueva sala, y aun así recibió una página 404.
@putty Es posible que este sea un problema con tu nombre de usuario en el sitio. La ruta en tu grabación de pantalla termina con /invited-by/derek.putnam, y la ruta actual rechaza los puntos en los nombres de usuario. Esto debería solucionarlo:
También puedes probarlo en tu sitio compartiendo el enlace sin la parte /invited-by/....
Estuvimos usando esto durante el fin de semana con buenos resultados Un error o característica inesperada que encontramos es que el sistema soporta micrófonos estéreo. Normalmente, en el software de videoconferencia, los canales izquierdo y derecho se reducen a mono, ya que normalmente se usa hardware de micrófono mono para capturar este tipo de audio. (Esto también reduce teóricamente el uso de ancho de banda). La solución de Discourse actualmente transmite micrófonos estéreo completos.
Sin embargo, algunos micrófonos solo producen salida en un canal y dejan el otro vacío. (Quizás esto sea más típico en interfaces de audio para profesionales con múltiples entradas, pero imagino que algunos micrófonos económicos también podrían hacer esto). Esto resulta en que los oyentes solo escuchen a ese hablante en el oído izquierdo o derecho. En realidad, no me di cuenta de esto, pero al parecer Mumble, Discord, Nextcloud, Jitsi, juegos, etc., todos reducen a mono.
Por lo tanto, recomendaría que por defecto se reduzca la señal de audio del micrófono (no la señal de audio de la compartición de pantalla, que debería ser un conjunto de canales separado) a mono. En general, probablemente haya pocas situaciones en las que el usuario realmente desee un campo de visión amplio para capturar audio durante una llamada, quizás si una banda de música lo usara para transmitir en directo a sus fans. En ese caso, si el usuario tiene específicamente un micrófono estéreo de campo amplio y desea usarlo, déjale activarlo a través de la configuración, lo que desactivaría la reducción a mono.
Gracias por la información, lo intentaré la próxima vez, pero sería más ideal si pudiéramos activar o desactivar esta opción por separado, sin tener que reducir la tasa de bits.
Llevamos un par de semanas usando las salas de voz, con tamaños de grupo limitados (máx. 5 personas). Hasta ahora, todo funciona bien, ¡enhorabuena! Me gustaría separar el backend técnico de la aplicación web y la base de datos de Discourse. ¿Existe alguna buena documentación sobre cómo configurar un servidor de Livekit con Docker Compose (antes de preguntarle a Claude )?
En la configuración predeterminada, y también en la configuración de LiveKit, Discourse sigue asumiendo la misma cantidad de responsabilidades. Mesh es una buena opción por defecto, y si te funciona, te recomendaría mantenerla hasta que la superes.
Gracias @Falco, sería aún mejor si no tuviéramos que cambiar nada. En ese caso, habilitaré la función para todas las comunidades en nuestra instancia, pero limitada a 5 personas por sala. Para la mayoría de las reuniones improvisadas, esto es más que suficiente.
Una nota sobre la privacidad: en el futuro (quizás en una etapa posterior del proyecto «Sala de voz»), necesitaremos una solución documentada para cumplir plenamente con el RGPD: actualmente, stun.l.google.com y global.stun.twilio.com son los predeterminados. Ambos están basados en Estados Unidos y, por lo tanto, deben cumplir con la US Cloud Act, lo cual entra en conflicto con la jurisdicción europea.
El anuncio del OP enumera «salas públicas, restringidas a grupos y privadas» bajo los permisos de sala, pero no puedo encontrar dónde configurar la restricción de grupo en una sala.
Mi caso de uso: una Sala visible y accesible solo para los miembros de un grupo específico, básicamente como una Categoría. Las configuraciones voice_allowed_groups y voice_create_room_allowed_groups son a nivel de sitio, por lo que no cubren lo que necesito aquí.
En el editor de salas solo veo el interruptor Público y la gestión de miembros por usuario.
¿Se ha implementado la restricción por grupo a nivel de sala? Si es así, ¿dónde está la configuración? Si no, ¿está previsto? Estaré encantado de probarlo.
Para muchas de mis comunidades, Categoría, Chat y Voice serían recursos que un Grupo desearía tener para su uso exclusivo, por lo que poder controlar el acceso a ellos por Grupo está muy alto en mi lista de prioridades.
Como mencionaste, @mcwumbly tiene un plan en la hoja de ruta para una nueva interfaz y estándar para controlar el acceso a funciones como salas de chat y salas de voz. Esto va a ocurrir, pero aún no está listo.