Re: videoconferencia, webcam, ekiga sin sonido
El Miércoles, 18 de Julio de 2007, Constructora Pando escribió:
> On 7/17/07, Iñaki Baz Castillo <ibc.listas@aliax.net> wrote:
> > El Martes, 17 de Julio de 2007, Constructora Pando escribió:
> > > Y ahoa si pude establecer una llamada, escuchaba que me respondian,
> > > pero el oro lado no me escuchaba a mi.... por lo que ven, he avanzado
> > > la mitad.... ¿alguna pista que me pudieran dar para resolver este
> > > problema?
> >
> > El audio en un sólo sentido es típico problema de NAT. Para solucionarlo
> > existen diferentes alternativas:
> >
> > * De lado de servidor:
> > - Emplear un proxy RTP y "engañar" a los clientes para que envíen allí el
> > audio. También es necesario que el proxy SIP reescriba las cabeceras SIP
> > y "corrija" las direcciones privadas poniendo la pública del NAT.
> >
> > * De lado de cliente:
> > - Redirigir puerto SIP y RTP al cliente. Obviamente es una guarrada.
> > - STUN: Muy buena opción. Es un protocolo que descubre el tipo de NAT y
> > averigua porqué IP saldrá su señalización SIP y el tráfico RTP de
> > audio/vídeo y coloca esas IP's y puertos en las cabeceras SIP. Por
> > desgracia no funciona con NAT simétrico (un NAT muy común en routers ADSL
> > comerciales).
> >
> > Lo mejor sin duda, probar con STUN. En Twinkle para ello vete a la
> > sección "NAT" y selecciona "STUN", y como servidor de STUN puedes poner:
> > stun.ekiga.net.
> > Luego Twinkle hará la comprobación y si tienes NAT simétrico te dirá que
> > no sirve.
> >
> > Si usas Twinkle para conectarte con algún proveedor SIP como OpenWengo
> > puedes mirar los datos de conexión en la web de OpenWengo (tras loguearte
> > con utu usuario). Te indican tu nombre de usuario y contraseña
> > (contraseña curiosamente distinta a si usas el propio cliente
> > wengophone), así como los datos a poner para el servidor de STUN y tal. O
> > sino, OpenWengo emplea un túnel en plan proxy RTP por lo que te soluciona
> > transparentemente el tema del NAT con único inconveniente de que tu
> > sonido pasa por dicho túnel.
>
> Muchas gracias Iñaki... trataré de documentarme un poco para entender
> las alternativas de solución que me das... la última esta mas a mi
> alcance,
> aunque debo darme un tiempo para entender eso de 'proxy RTP'
> y 'NAT' y como se implementa...
Humm, no no, realmente esa solución es de lado de servidor, es decir, si por
ejemplo usas el servidor SIP de Ekiga.net o el de openwengo.org entonces
ELLOS son los que posiblemente implementen una solución de proxy RTP para que
tú no tengas problemas de NAT y ni siquiera necesites soluciones de lado de
cliente (como STUN o redirigir puertos).
El símil sería el del FTP y el NAT y los firewalls:
- Cuando estás tras NAT y haces una conexión FTP, en los datos de la conexión
de control es donde indicas qué puerto se va a usar para la transferencia de
datos. Obviamente ese puerto no está abierto en tu firewall así que fallaría,
pero:
- Existe un módulo para Iptables que lee los paquetes FTP y averigua que
puerto se ha elegido, de tal forma que abre el puerto necesario. Esta sería
una solución de cliente (en cuanto a que se obra en su LAN).
Yo lo que te recomiendo es que uses OpenWengo que te solucionan el problema
del NAT y es un SIP estándar por lo que podrías hablar con otras cuentas SIP
(de Ekiga.net por ejemplo).
Saludos.
--
Iñaki Baz Castillo
Reply to: