2011-01-26 9 views
8

Implementiamo una soluzione basata su SIP e abbiamo configurato l'installazione per funzionare con RTPProxy. In questo momento stiamo eseguendo il routing di tutto tramite RTPProxy perché abbiamo riscontrato alcuni problemi con il trasporto dei contenuti multimediali basato su ICE. Se non ci sbagliamo, è necessario un server di inoltro centrale per inoltrare i dati di streaming tra due client se si trovano dietro NAT simmetrici. In pratica, questa è una grande percentuale di tutti gli utenti consumer? Quanta larghezza di banda risparmiamo se implementiamo il routing appropriato per saltare il server relay quando non è necessario. Ci sono soluzioni migliori che ci mancano?Quale percentuale di utenti si trova dietro NAT simmetrici, ad esempio che il traffico "p2p" deve essere inoltrato?

risposta

3

Un'alta percentuale (se non la maggioranza) degli utenti domestici utilizza NAT, in quanto è quello che quei router xDSL/via cavo utilizzano per fornire l'accesso di rete alla rete locale.

È possibile in teoria utilizzare UPnP per aprire le porte e impostare le regole di inoltro sul router per passare attraverso il NAT in modo trasparente. Sfortunatamente (o fortunatamente, a seconda di chi sei) molti utenti disabilitano UPnP come una cosa ovvia sul loro router e potrebbero non apprezzare la necessità di aggiungere manualmente le regole di inoltro.

Quello che potresti essere in grado di fare (e ciò che Skype fa AFAIK) è avere alcuni utenti che hanno percorsi di rete chiari e una larghezza di banda sufficiente come nodi di inoltro. Oltre ai problemi di routing e QoS, dovresti almeno trovare un modo per garantire la privacy di tutti i dati inoltrati da chiunque, incluso il proprietario del nodo relay. Inoltre, potrebbero esserci problemi legali da risolvere con questo approccio, a parte quelli tecnici.

8

In caduta ordine di utilità:

  • C'è un collegamento diretto tra i due punti finali in entrambe le direzioni. Ti connetti e sei sostanzialmente finito.
  • C'è una connessione diretta tra i due endpoint in una direzione. In tal caso ti connetti solo nella giusta direzione provando entrambi.
  • Entrambe le parti sono dietro NATs di qualche tipo.
    • Fortunatamente, UPnP lavora in una delle estremità, è possibile aggiornare il collegamento allo schema sopra
    • UPnP non funziona, ma STUN fa. Usalo per fare un buco nel NAT. Ci sono un paio di protocolli diversi, ma il trucco generale è quello di negoziare tramite un intermediario che coordina il piercing NAT.
    • Si ricade per consentire a un altro nodo della rete di agire come proxy di inoltro.

Se si implementa l'elenco completo di cui sopra, allora si deve rinunciare a molto pochi collegamenti e non è necessario spendere molto tempo su utilizzo della larghezza di banda a proxy. Il protocollo BitTorrent, di cui sono in qualche modo familiare, di solito si ferma su UPnP, ma fornisce un test integrato per verificare la connettività attraverso il NAT.

Uno si chiede davvero perché IPv6 non sia stato implementato prima: questo è uno spreco di tempo per i programmatori.

+2

buona su IPv6 implementazione: P –

Problemi correlati