adrian mis saludos:
a ver openfire+ofmeet lo habia probado en varias ocaciones pero tenia la
limitante de chrome, en este caso probe jitsi meet, este ultimo no tiene
mucha historia para implementar puesto que es muy facil, no en mi caso por
que donde lo implemente es en una maquina virtual sin acceso a internet por
lo que tuve que descargar los .deb a fin con su implementacion rescatarlos
y pasarlos a la maquina donde hiba a hacer la prueba, hasta hi todo muy
bien se podia acceder desde un navegador sea firefox, chrome, ect mediante
la web, el problema estaba a l hora de acceder mediante una señal wifi al
servicio, para esto tengo un servidor con una tarjeta pci wifi con un
hostapd y dhcp entregando direcciones ip para el segmento 172.10.10.* este
segmento luego en iptables es nateado para el segmento 192.168.1.* que es
el de la red local donde se encuentra jitsi meet.
el problema esta en que las apk relacionadas con jitsi necesitan un
certificado valido para conectarse con el servicio, al principio pence que
era problemas del nateado pero no, simplemente es problema de que debe
existir un certificado valido es decir validado por una entidad
certificadora, como mi caso no se trata de un dominio real no creo que
pueda hacer mucho, por lo que decidi probar directamente con un navegador
desde los dispositivos moviles activandole la opcion de escritorio, puesto
que con la version para moviles automaticamente te remite a iniciar desde
la apk a fin o descargarla.
un abrazo hermano
El mar., 5 may. 2020 a las 4:00, Arian Molina Aguilera ()
escribió:
> En 4 de mayo de 2020 9:37:57 p. m. Ariel Alvarez
> escribió:
>
> > ya logre hacer lo que queria, ante todo adrian una vez mas gracias por tu
> > interes, ayuda y apollo, les describo mas menos.
> > no hiso falta cambiar nada en el nat de iptables mantengo el
> > enmascaramiento en este.
> > resulta que el nat siempre me estuvo funcionando pero daba por sentado
> que
> > habia algun error en este puesto que las conexiones que hacia desde
> > dispositivos moviles a travez del nat no funcionaban por algo.
> > si estan funcionando lo que las aplicaciones jitsi meet para moviles
> > requieren de un certificado real avalado por una entidad certificadora,
> sea
> > de pago o alguna de las variantes gratos pero debe ser valido, en mi caso
> > estaba incursionando en una maquina virtual aislada completamente de
> > internet.
> > como resolvi el problema fue usando en el dispositivo movil chrome y
> > habilitando en este la version de escritorio, probe hacer esto con
> firefox
> > pero el cosumo de memoria es tan alto que todo se ve en camara lenta, con
> > chrome va muy bien.
> >
> > gracias una vez mas por la ayuda.
> >
> > El sáb., 2 may. 2020 a las 10:21, Arian Molina Aguilera (<
> > linuxc...@teknik.io>) escribió:
> >
> >> En 2 de mayo de 2020 12:48:38 a. m. Ariel Alvarez <
> ariel1cu2...@gmail.com>
> >>
> >> escribió:
> >>
> >> > aprovechando el tema recien estoy probando jitsi meet como
> alternativa a
> >> > video conferencias, alguien que tenga un poco mas de kilometros
> >> recorridos
> >> > sobre el tema pudo lograr que se comuniquen a travez de un NAT.
> explico
> >> > mejor el servicio en la red local me funciona bien pero cuando se
> conecta
> >> > algun dispositivo movil a la señal wifi esta hace un nat hacia la red
> >> local
> >> > y no llega a establecer conexion con la sala de videoconferencia ya
> >> creada.
> >> >
> >> > esta es mi config en
> /etc/jitsi/videobridge/sip-communicator.properties
> >> >
> >> > org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
> >> > #org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=
> >> > meet-jit-si-turnrelay.jitsi.net:443
> >> > org.jitsi.videobridge.ENABLE_STATISTICS=true
> >> > org.jitsi.videobridge.STATISTICS_TRANSPORT=muc
> >> > org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=localhost
> >> > org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth.192.168.1.101
> >> > org.jitsi.videobridge.xmpp.user.shard.USERNAME=jvb
> >> > org.jitsi.videobridge.xmpp.user.shard.PASSWORD=7ISiOaVg
> >> >
> >>
> org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=jvbbrew...@internal.auth.192.168.1.101
> >> >
> >>
> org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=e95a5b66-19ee-4ed0-adf2-2254239c8e71
> >> > org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=172.10.10.1
> >> > org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=192.168.1.101
> >> > org.jitsi.videobridge.rest.jetty.port=
> >> > org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT=12345
> >> > org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
> >> > org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=443
> >> > org.ice4j.ipv6.DISABLED=true
> >> >
> >> >
> >> > gracias de antemano y disculpen si irrumpi en el hilo.
> >> >
> >> >
> >> > El vie., 1 may. 2020 a las 19:04, Lic. Humberto Y. Conde Armentero (<
> >> > informat...@sepro.co.cu>) escribió:
> >> >
> >> >> Una buena alternativa es OpenMCU-ru
> >> >>
> >> >> .
> >> >>
> >> >> En 30 de abril de 2020 16:50:52
> >> >> escribió:
> >> >
