¿Qué porcentaje de usuarios están detrás de NAT simétricos, de modo que el tráfico "p2p" debe retransmitirse?

Question

Estamos implementando una solución basada en SIP y hemos configurado la configuración para que funcione con RTPProxy. En este momento, estamos enrutando todo a través de RTPProxy ya que tuvimos algunos problemas con el transporte de medios que dependen de ICE. Si no nos equivocamos, se necesita un servidor de retransmisión central para retransmitir datos de transmisión entre dos clientes si están detrás de NAT simétricos. En la práctica, ¿se trata de un gran porcentaje de todos los usuarios consumidores? Cuánto ancho de banda queremos ahorrar si implementamos el enrutamiento adecuado para omitir el servidor de retransmisión cuando no sea necesario. ¿Hay mejores soluciones que nos faltan?

Answer 1

Un gran porcentaje (si no la mayoría) de los usuarios domésticos usa NAT, ya que eso es lo que utilizan los enrutadores xDSL/cable para proporcionar acceso a la red local.

En teoría, puede usar UPnP para abrir puertos y configurar las reglas de reenvío en el enrutador para que atraviesen NAT de forma transparente. Desafortunadamente (o afortunadamente, dependiendo de quién sea), muchos usuarios deshabilitan UPnP de forma rutinaria en su enrutador y es posible que no aprecien tener que agregar reglas de reenvío manualmente.

Lo que podría hacer (y lo que Skype hace AFAIK) es que algunos de los usuarios que tienen rutas de red claras y un ancho de banda suficiente actúen como nodos de retransmisión. Además de los problemas de enrutamiento y QoS, al menos deberá encontrar la manera de garantizar la privacidad de los datos retransmitidos de cualquier persona, incluido el propietario del nodo de retransmisión. Además, podría haber problemas legales para resolver con este enfoque, además de los técnicos.

Answer 2

Al caer el fin de utilidad:

• Hay una conexión directa entre los dos puntos finales en ambas direcciones. Simplemente te conectas y esencialmente has terminado.
• Hay una conexión directa entre los dos puntos finales en dirección. En ese caso, simplemente te conectas en la dirección correcta probando ambos.
• Ambas partes están detrás de los NAT de algún tipo.
  • Por suerte, UPnP trabaja en un extremo, a continuación, puede actualizar la conexión con el esquema anterior
  • UPnP no funciona, pero lo hace STUN. Úselo para perforar un agujero en el NAT. Hay un par de protocolos diferentes, pero el truco general es negociar a través de un intermediario que coordina el piercing NAT.
  • Retrocede para permitir que otro nodo en la red actúe como un proxy de retransmisión.

Si implementa la lista completa de arriba, entonces usted tiene que renunciar a muy pocas conexiones y no tienen que pasar mucho tiempo en la utilización del ancho de banda a los proxies. El protocolo BitTorrent, del que estoy algo familiar, generalmente se detiene en UPnP, pero proporciona una prueba integrada para probar la conectividad a través de NAT.

Uno realmente se pregunta por qué IPv6 no se implementó antes; esto es una pérdida de tiempo para los programadores.

Answer 3

Según Google, aproximadamente el 8% del tráfico tiene que ser transmitida: http://code.google.com/apis/talk/libjingle/important_concepts.html encuesta

Answer 4

tipos de NAT mundo real (no es un gran conjunto de datos, sin embargo):

http://nattest.net.in.tum.de/results.php