El Miércoles, 18 de Julio de 2007, Constructora Pando escribió: > On 7/17/07, Iñaki Baz Castillo <[EMAIL PROTECTED]> 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
