Immaginiamo una conversazione UDP peer-to-peer tra due client: il client A e il client B sono in delle reti che hanno un firewall. Supponendo che A abbia l'indirizzo IP di B, di solito la nuova conversazione in arrivo viene rifiutata dal firewall B; quindi, A non può avviare un handshake con B e viceversa.

Cosa possiamo fare? Abbiamo diverse alternative:

*   **Callback:** la tecnica più semplice, almeno uno dei due peer è al di fuori di una rete con firewall e ha un indirizzo pubblico. Supponendo che la conversazione utilizza un server esterno S che mantiene l'IP delle postazioni e ha una conversazione già avviata con entrambe le parti; B non può ancora provare a connettersi con A. Tuttavia, A può effettivamente chiamare B. Quindi, dobbiamo approfittare del fatto che B è fuori dal firewall e impostare la callback: dobbiamo sfruttare la presenza delle connessioni con il server. Quando B vuole chiamare A, A comunica la sua disponibilità al server e il server, a causa della comunicazione TCP permanente con A, dice ad A di chiamare B e dà ad A l'indirizzo IP di B. Quindi, A chiama B e B può ora rispondere. Questa tecnica non è utile se entrambi gli interlocutori sono dietro un firewall perché A non potrebbe chiamare direttamente B, il firewall bloccherebbe il pacchetto perché appartiene a una nuova conversazione in arrivo;
*   **Perforazione (hole punching):** supponendo di avere due stazioni peer-to-peer e un server, A e B vogliono comunicare e conoscere sia l'indirizzo IP che la porta di destinazione P. B invierà pacchetti UDP all'IP e P di A sapendo che i pacchetti verranno scartati ma nel firewall B verrà inserita una nuova voce contrassegnando la conversazione tra A e B come NEW. In questo modo il server può informare A che B ha inviato dei pacchetti ma non sono arrivati. Quindi, A può iniettare pacchetti di risposta senza doverli ricevere. B riceverà i pacchetti e li contrassegnerà come ESTABLISHED. Questo può essere possibile solo se A e B hanno indirizzo pubblico, ci saranno problemi se c'è un firewall NAT. Se c'è un firewall NAT il problema è più complicato perché la porta di origine e l'indirizzo IP saranno diversi, e ovviamente né A né B conoscono la mappatura di porta e IP. A invia pacchetti a B senza sapere in quale porta B è mappata, A invia brutalmente pacchetti a tutte le porte UDP. Ad un certo punto, A avrà successo.

Cosa possiamo fare nel caso in cui la conversazione peer-to-peer non possa essere stabilita?
*   Utilizzare il server come intermediario che trasporta i pacchetti da A a B;
*   Il server può anche selezionare un'altra entità che ha un indirizzo IP pubblico e la nuova entità sarà eletta come **relay**.