Normalmente, los paquetes viajan en una red desde su origen (por ejemplo su ordenador) a su destino (como por ejemplo www.kernel.org) a través de varios enlaces diferentes: unos 19 desde donde yo estoy en Australia (esto lo dice Rusty, claro). Ninguno de estos enlaces altera realmente el paquete: simplemente lo envían un paso adelante.
Si uno de estos enlaces hiciera NAT, podría alterar el origen o destino del paquete según pasa a través suyo. Como puede imaginar, ésta no es la función para la que se diseñó el sistema, y por tanto NAT es siempre un tanto enrevesado. Normalmente, el enlace que esté haciendo NAT recordará cómo jugueteó con el paquete, para hacer la acción inversa con el paquete de respuesta, de manera que todo funciona como se esperaba.
¿Que es H.323?
El estándar H.323 proporciona la base para la transmisión de voz, datos y vídeo sobre redes no orientadas a conexión y que no ofrecen un grado de calidad del servicio, como son las basadas en IP, de manera tal que las aplicaciones y productos puedan ínter operar, permitiendo la comunicación entre los usuarios sin que éstos se preocupen por la compatibilidad de sus sistemas. La LAN sobre la que los terminales H.323 se comunican puede ser un simple segmento o un anillo, o múltiples segmentos con una topología compleja, lo que puede resultar en un grado variable de rendimiento.
H.323 fija los estándares para la comunicación de voz y vídeo sobre redes de área local, con cualquier protocolo que por su propia naturaleza presentan una gran latencia y no garantizan una determinada calidad del servicio (QoS). Para la conferencia de datos se apoya en la norma T.120, con lo que en conjunto soporta las aplicaciones multimedia. Los terminales y equipos conforme a H.323 pueden tratar voz en tiempo real, datos y vídeo.
El estándar contempla el control de la llamada, gestión de la información y ancho de banda para una comunicación punto a punto y multipunto, dentro de la LAN, así como define interfaces entre la LAN y otras redes externas, como puede ser la RDSI. Es una parte de una serie de especificaciones para videoconferencia sobre distintos tipos de redes, que incluyen desde la H.320 a la H.324, estas dos válidas para RTB (Red Telefónica Básica) y RTC (Red Telefónica Conmutada), respectivamente.
H.323 establece los estándares para la compresión y descompresión de audio y vídeo, asegurando que los equipos de distintos fabricantes se entiendan. Así, los usuarios no se tienen que preocupar de cómo el equipo receptor actúe, siempre y cuando cumpla este estándar. La gestión del ancho de banda disponible para evitar que la LAN se colapse con la comunicación de audio y vídeo, por ejemplo, limitando el número de conexiones simultáneas, también está contemplada en el estándar.
La norma H.323 hace uso de los procedimientos de señalización de los canales lógicos contenidos en la norma H.245, en los que el contenido de cada uno de los canales se define cuando se abre. Estos procedimientos se proporcionan para fijar las prestaciones del emisor y receptor, el establecimiento de la llamada, intercambio de información, terminación de la llamada y como se codifica y decodifica.
Cuando se origina una llamada telefónica sobre Internet, los dos terminales deben negociar cual de los dos ejerce el control, de manera tal que sólo uno de ellos origine los mensajes especiales de control. Una cuestión importante es, como se ha dicho, que se deben determinar las capacidades de los sistemas, de forma que no se permita la transmisión de datos si no pueden ser gestionados por el receptor.
La comunicación bajo H.323 contempla las señales de audio y vídeo. La señal de audio se digitaliza y se comprime bajo uno de los algoritmos soportados, tales como el G.711 o G.723, y la señal de vídeo (opcional) se trata con la norma H.261 o H.263. Los datos (opcional) se manejan bajo el estándar T.120 que permite la compartición de aplicaciones en conferencias punto a punto y multipunto. Una característica de la telefonía sobre una LAN o Internet es que se permite la información de vídeo sobre la de audio (videoconferencia), formateada de acuerdo con el estándar H.261 o H.263, formando parte de la carga útil del paquete RTP. Dado que se envían sólo los cambios entre cuadros resulta muy sensible a la pérdida de paquetes, lo que da origen a la distorsión de la imagen recibida.
Razones para usar NEWNAT
La razón es muy simple esta guía esta armada para personas que necesitan implementar H323 o RTP.
Les dejo un links para que puedan profundizar en el tema.
http://greco.dit.upm.es/~david/TAR/trabajos2002/01-SIP-%20Diego-Acosta.pdf
Pido mil disculpas a aquellas personas que buscan en esta guía encontrar información de cómo poder implementar NAT, teniendo en cuenta que nos vamos a saltear muchos pasos obvios de Iptables.
Acá les dejo un link muy bueno que los pone al tanto de que es NAT y Iptables
http://www.insflug.org/COMOs/NAT-COMO/NAT-COMO.html
Puesta al día rápida con respecto a los núcleos 2.0 y 2.2
Lo siento por aquellos que todavía estén aturdidos por la transición desde 2.0 (ipfwadm) a 2.2 (ipchains). Hay buenas y malas noticias.
Primero, puede seguir usando ipchains o ipfwadm como antes. Para hacerlo, necesita cargar los módulos del núcleo «ipchains.o» o «ipfwadm.o» que encontrará en la última distribución de netfilter. Son mutuamente exclusivos (está advertido), y no deberían combinarse con ningún otro módulo de netfilter.
Una vez haya instalado uno de estos módulos puede utilizar ipchains e ipfwadm con normalidad, excepto por las siguientes diferencias:
- Establecer los tiempos límite (time out) con ipchains -M -S o ipfwadm -M -s no hace nada. Como los límites de tiempo con la nueva infraestructura NAT son más grandes, no debería haber problema.
- Los campos init_seq, delta y previous_delta en la lista ampliada de enmascaramiento (verbose masquerade listing) siempre son 0.
- Listar los contadores y ponerlos a cero al mismo tiempo «-Z -L» ya no funciona: los contadores no se pondrán a cero.
