2
FIELD OF THE INVENTION
The present invention relates to a method and system for firewall and NAT
(network address translator) traversal for establishing secure direct peer-to-peer
real-time communication. The communication includes media streaming, voice
on internet protocol (VOIP), etc., between peers suitable for multicasting and
hosting media servers on hosts obscured by firewalls and behind any network
address translator (NAT) configuration.
BACKGROUND OF THE INVENTION
Teredo tunneling uses network address translator to traverse ipv4 packets
between teredo clients. It cannot cross symmetric network address translator
without relay. Other techniques like hole punching also do not work under the
scenario. Also most firewalls may block easy transmission. Document US 2004
0064584 provides application and method for assisting in network address
translator traversal.
To create and maintain a network address translator bind, data packets need to
flow from a private network to the public network. Therefore, the device in the
private network that will use the network address translator bind has to send the
data packets. This may not always be convenient, and the device may not be

3
able to send data packets frequently. The document provides methods for
creating, maintaining and discovering network address translator binds. A
dedicated device called an internet protocol (IP) faker sends packets through the
network address translator, whereby the source fields of the packets are edited
to be the internet protocol address the port of the real device. When the packets
are received by the network address translator and their headers analyzed, the
network address translator is fooled into determining that the packets are being
sent by the real device, thereby allowing the internet protocol faker to open a
network address translator bind and maintain the network address translator
bind on behalf of the real device. The document is not actually for network
address translator traversal and requires dedicated hardware for assistance.
Document US 2006 0182100 provides automated network address translator
traversal for peer-to-peer networks. This document relates to systems and
methods that facilitate direct network communications between peers that
operate behind network address translators (NAT). In one aspect the document
provides a network communications system. The system comprises one or more
network address translators (NAT) to communicate data across a network
between peers. A protocol selection component selects automatically among a
plurality of protocols according to one or more network address translator types
for determining a subset of the protocols which will facilitate communications
between the peers.

4
Firewalls and network address translators (NAT's) of Document US
2006/0215684 provide many advantages for client and the internet itself.
However, these devices break many existing transmission control protocol (TCP)
/ internet protocol (IP) applications, and other communications like UDP, ICMP,
since they conceal the identity of internet protocol clients (i.e., peers) and block
transmission control protocol (TCP) call setup requests. Firewalls and network
address translators (NAT's) make it impossible for one transmission control
protocol (TCP) peer to discover another and establish a connection.
Embodiments disclosed in this document provide a system and a protocol to
enable two transmission control protocol (TCP) peers that exist behind one or
more firewalls and network address translators (NAT's) to automatically setup a
true peer-to-peer transmission control protocol connection and exchange data
without making changes to the firewall or network address translators devices or
existing transmission control protocol based applications. In embodiments
described in this document, the synchronization between the blind
transmission control protocol peers is achieved using a system that consists of
a registration server, an agent application, and a virtual network interface that
together relay and replicate the control signals between the two transmission
control protocol peers. In addition, embodiments of this document are also used
to traverse the network address translator and establish a bi-directional peer-to-

5
peer transmission control protocol connection in the firewall. This document is
for transmission control protocol (TCP) connections and unsuitable for real time
streaming.
Document WO / 2005 / 088466 provides a system and method for establishing
and maintaining two-way peer-to-peer network communication between clients
who are behind symmetric firewalls / network address translators (NAT's). In
one embodiment described in the document it uses third party address-and-port
discovery servers for ascertaining the nature and port-mapping matrix of a given
client's firewall / network address translator. A universal data packeting (UDP)
hole punch method is employed for ports within a predicted range, and the
source port of the first successful forwarding of an inbound packet is used by the
client for subsequent outgoing traffic. The method occurs symmetrically so that
both client's firewalls receive packets for which the source / destination ports and
source / destination addresses fully-tuple-match with a previous client request
originating from within the protected network, and therefore forwards packets to
the respective clients successfully (peer-to-peer). In addition, the system and
method allows monitoring, management, and prevention of connections by
firewally / network address translator administrators.
None of the existing art as mentioned above or any available document describes
a method where a client behind symmetric network address translator might be

6
reached by any host on the internet whether in private or private domain. In
other words, there is no existing method which works for all kinds of network
address translator, firewall at all times and guarantees that the external host
may initiate sending data directly to the client behind symmetric network address
translator and that such data may reach the client behind symmetric network
address translator without the client behind network address translator first
sending a welcome packet to the external host (which the external host must
receive first before it is able to send any data packets to the client behind
symmetric network address translator. No method exists which does this without
port-forwarding or using relays or proxies or using more than one external
server.
Using existing art, the client behind symmetric network address translator will
have to first send a data packet to the server and the server will reply back on
the internet protocol, port bindings on the packet it received to initiate sending
media data. For this even if the multi-cast server is public, it must rely on
another third party server to inform the client behind network address translator
to connect to it. On its own it cannot directly start sending media packets to the
client behind symmetric network address translator.
To receive data the client behind symmetric network address translator must
request the server first so that the server may be able to send the necessary

7
data. The current methods either do not work every time for all network address
translators (if port prediction is used), else they use relays or port forwarding
which again are costly or not applicable to all network address translators.
Another major weakness of the current art is that if a client behind network
address translator wants to connect with / receive data from a large number of
hosts on the public internet simultaneously, then there is an upper-limit on the
same because of the number of network address translator mappings permissible
on a network address translator and hence, the number of such connections is
very limited. This is limited by the maximum number of available external ports
that can be assigned to an internal end-point.
With the current network address translator traversal methods if such a situation
is created the number of assignable network address translator mappings with
the network address translator will be reduced and may eventually be empty. In
such a case either the other internal clients will not be able to communicate with
the hosts on public internet or new connection requests from internal hosts will
cause existing connection to be broken.
This is because a network address translator may not be able to create mappings
more than the number of unique external ports and internet protocols it can
provide for each mapping.

8
The current invention allows a client behind any type of network address
translator and specified firewall configuration to be able to receive real-time
communications (including media streaming) from with multiple hosts on the
internet with just one network address translator session and will not overburden
the network address translator for resources and can maintain such
communications for long durations without limiting the connectivity of other
clients behind the same network address translator or configuration of multiple
network address translators.
The existing art also are unable to allow a receiver to receive multi-cast from
multiple streaming servers outside.
If a large number of such servers are being connected to by a host then the
connections of other hosts behind the network address translator with hosts /
servers might be broken or new ones may not be allowed.
Thus, the network address translator resources will be constrained.
At present network address translator poses a problem for all applications (like
VOIP, gaining and sharing), desirous of direct peer-to-peer connectivity between
the end points. Nowadays most internet connections use private internet

9
protocol (IP) obscured by network address translator. Network address
translator allows only outbound connections, if not port forwarded, and blocks
any incoming request.
With tremendous growth of internet and the lack of ipv4 addresses, came the
need for network address translator devices which blocked the seamless
connectivity and power of the internet by blocking direct peer-to-peer
connectivity by creating private address spaces. The problem was not noticed
earlier because only some public servers were accessed.
SUMMARY OF THE INVENTION
One object of the present invention is to remove hardware and software
dependencies for solving network address translator and firewall traversal
problem and allowing direct peer-to-peer communication across all classes
(classified on the type of end-point connectivity supported i.e. the type of
address-port translation) of network address translators (including all types of
symmetric NAT, port restricted cone NAT and so on) and firewalls (as described
above and in the pages to follow) which block other network address translator
traversal methods, thus allowing direct reachability of client behind symmetric
network address translator.

10
Another object of the invention is to provide a single method for network address
translator, firewall traversal which works for almost all kinds of firewall, network
address translator configurations at both the end-points.
This will allow a client behind network address translator and firewall to maintain
direct peer-to-peer connectivity with large number of hosts outside of the
network address translator, all at the same time, for long durations without
monopolizing on network address translator resources or disrupting the
connectivity of other hosts behind the same network address translator with the
internet because of the same. The invention is hence a method for establishing
direct peer-to-peer communication using just one external server and makes at
most two network address translator mappings (at all the end-point network
address translators i.e. all the network address translators which obscure / hide
the end-point hosts which have to communicate directly) to connect with large
number of hosts outside.
The invention also allows a host behind network address translator to connect to
large number of public servers for real-time communications without straining on
network address translator resources or disrupting the connectivity of other hosts
behind network address translator:

11
A method is provided for traversal of firewall (both ingress-blocks incoming
universal data packeting (UDP) packets and egress-blocks and those that do not
block outbound packets of both transmission control protocol (TCP) and universal
data packeting (UDP) protocols) and network address translator for real-time
communication between the end-points.
To accomplish all the above no port forwarding, proxy, gateways, relays or any
other dedicated hardware and software is required and to achieve all this no new
network infrastructure or no changes in any of the current network
infrastructure, or in programming of any public network infrastructure or no new
standard for the same are required. The goal of the invention is to achieve all
this with the current network infrastructure.
One more object of the present invention is to create a scenario wherein any
host in a private network behind NAT, firewall (except firewalls that block both
outbound UDP and TCP traffic also) may be configured as a server directly
accessible to all.
Yet another object of the present invention is to provide a method which allows
direct communication between two peers separated by egress firewalls and with
same NAT consideration as described hereinafter.

12
A further object of the present invention is to provide a method and system
which allows the simplification of this central server and the connection making
procedure (any actions after which the two clients may interact directly and more
specifically the peer initiating the request may send the packets directly to its
desired target) between the clients the same irrespective if the kinds of NAT in
between.
A still further object of the present invention is to provide a single method for
allowing a peer behind any kind of NAT and firewall consideration to be reached
by any other peer behind any NAT / firewall consideration.
Types of NAT supported: cone, pure cone, port restricted cone, symmetric etc.
Firewalls: all except those that block both outgoing TCP and UDP packets within
all available port ranges and do not block ICMP error messages.
Server to maintain peer information and to initiate direct peer-to-peer
communication by facilitating opening bi-directional communication channels.
The server maintains information regarding the peers, their names, passwords,
and authentication details IPs (external, internal).

13
Method to initiate connection between peers by the peer which wants to initiate
the connection) which would be used by the peers behind NAT and firewall. A
host which is in the listening mode and can be behind any NAT or multiple
combinations of NAT and all those firewalls that do not block both outgoing TCP
and UDP packets. This host can either be a receiver of real time data from
multiple hosts on the internet or it can be configured as a server in which case it
can receive connection requests for streaming real time data / communication
from multiple hosts on the internet and will then be able to communicate with
each one of the multiple hosts separately as per their request.
Further the system mentioned above implements a filter layer to capture ,parse
& redistribute all ICMP packets received by the hosts (including fragmented
packets) to all applications requesting its service. Along with this it implements
layers on top of this driver which have the duty to identify which of the captured
packets / fragments are required by which application. This module parses the
information present in the ICMP packet and forwards it to the application by
passing any other IP protocol processing by the TCP / IP stack already present
on the system. This module not only passes the desired information to the
desired application but also informs the application which
client sent that packet. This information is encapsulated in the data sent to the
application so that application may identify the source as well as the details
identify to what real-time communication the packet belongs. This is because

14
the same application may be able to perform multiple real-time communications
with separate real-time streams from each of these sources which are
independent of each other. For example a host may receive media streams from
multiple servers on the public internet. The host shall identify which media
stream has come from which source using this information.
A transmitter or a system which seeks to receive media data from another peer
on the internet (which has been described above). This host can be behind any
NAT or combination of multiple NAT's and any firewall except those that block
both outgoing TCP, UDP connections and can not be configured by the host
using protocol like SOCKS (for the same) and except those that are configured to
block both incoming UDP and TCP packets in port ranges usable by the method
of the invention.
Additional authentication data are present in the communications.
Further the invention requires detecting the duration of NAT session and ICMP
timeout. This will be done by the peers by coordinating with the central server.
All the hosts wishing to receive data will open up such NAT mappings.
(Finalized configurations as are supported by the invention in its present form)
Thus both peers separated by any NAT, firewall configuration. Firewalls should
not block both outgoing TCP and UDP connections and close the connections or

15
block all kinds of ICMP error packet. Both the peers may be behind any number
of layers of NAT (i.e. behind multiple NAT's).
A preferred embodiment of the present invention provides a method for firewall
and NAT traversal for establishing secure direct peer-to-peer real-time
communication between a host and at least another host 2, comprising the steps
of: host 1 requesting a global server for details on host 2 to be contacted, and
for determining that the NAT of host 2 may receive communication out of order;
crafting a fragmented ICMP error packet from the details obtained from said
global server; and sending sequentially all fragments of said error packet to the
NAT of host 2.
BREIF DESCRIPTION OF THE ACCOMPANYING DRAWING
The invention can now be described in detail with the help of the figure of the
accompanying drawing in which
Figure 1 shows a timing chart of the operation of the present invention.
Figures 2
and 3 show in flow chart for the methods of the present invention.

16
DETAILED DESCRIPTION OF THE INVENTION
The present invention creates a scenario wherein any host in a private network
behind any network address translator, firewall (expect firewalls that block both
outbound universal data packeting (UDP) and transmission control protocol
transmission control protocol (TCP) traffic also) may be configured as a server
directly accessible to all.
Any public host on the internet or private hosts as are specified by the present
invention can connect to it without requiring port-forwarding or external relays or
any other dedicated hardware of proxies or gateways.
The method would allow any peer behind network address translator and firewall
to be reachable under almost all network address translator, and many firewalls
(all categories as are specified in the present invention). Using the method of
the present invention, a large number of public hosts behind differing kinds of
NAT / firewall may initiate connection requests to a host (working as a server)
behind any symmetric NAT configuration and those firewall configurations as are
described in the present invention without monopolizing on the NAT resources of
the host behind symmetric NAT. The server can then multi-cast media streams
in real time or be able to perform real-time interaction with all the requesting
clients simultaneously for long durations without monopolizing NAT resources in

17
a manner such that other systems behind the same NAT may not be able to
access the internet.
The end points can have real-time communication possible with large number of
such systems on the internet.
This is not possible because the NAT can allow on a small number of clients to
connect to the outside network simultaneously because all of the existing art has
to create a new session for interacting with a new host on the internet.
All this is not possible with the existing art and the method of the present
invention overcomes the following limitations of existing art:
Prior art methods do not work for all kinds of NAT and present invention uses
different methods for different NAT. Prior art method can be easily blocked by
firewall and require use of costly external third party servers for NAT discovery
process. Prior art methods use dedicated and costly relays to mediate traffic
between peers for certain cases, which causes delays in transfer of media data.
These methods require one mapping to communicate with each external host so
number of external hosts which can connect is limited.

18
In prior art different methods for NAT traversal are required for clients behind
different NAT's. So clients whose NAT characteristics cannot be discovered
because discovery procedures are blocked by firewall or NAT or because cost of
multiple servers cannot be borne, result in a situation where they cannot be
contacted. They have limited resources (external port internet protocol
combinations) on NAT. In the present invention real time communication is done
over universal data packeting (UDP) and not over transmission control protocol
(TCP) (for obvious reasons of satisfying real time behaviour). These can be
easily blocked by firewall. Real time data packets can thus be blocked by
firewall.
Hosts behind symmetric NAT cannot be reached directly by any other peer from
the outside network. If a host behind NAT is to be configured as a server for
real time streaming, then as per current art for firewall and NAT traversal the
client must know the type of NAT behind which the server is and must use
different method of authentication with the server for different NAT
configurations because host behind symmetric NAT, port restricted NAT is not
directly accessible (i.e. sending data to it is not possible without informing such a
host in advance through a relay).
Another big advantage of the present invention is that the host behind NAT can
be configured as a server accessible on the internet and will have the remote

19
wake up feature; according to which any remote client / host may be able to
wake it up as required. This was not possible for hosts using private internet
protocol until the present invention. This is because most wake up technologies
work on local area network (LAN) only or require the knowledge of the IP
address (of the host or its external IP, i.e. the external IP of its NAT). But the
hosts behind NAT have IP addresses such that packets addressed to those IP
addresses and sent from the public internet or from inside another NAT will not
reach hosts. This idea is not implemented in any of the existing products and no
patent comes out with a method to solve this.
This is the traditional NAT problem which imposes the limitation that to receive
any data packets, a host behind NAT is required to have a NAT mapping.
In the described prior art there is a method to keep alive such mapping. The
host must be awake or must use some sort of a fake packet sending device to
keep alive the NAT mapping on its behalf. This hardware will be an additional
cost and keeping a permanent mapping will be a constraint on NAT resources,
which will not allow any future connections for other hosts inside it. In case of
resource crunch the NAT may even drop old mappings, in which case the
mapping kept alive by the fake sender will be destroyed and a new one may get
generated, i.e. the external end-point of the mapping may get changed. In this
case remote wakeup of the host behind NAT will not be possible. In the former

20
case, other hosts inside NAT will be unable to communicate with any external
host.
Nowadays, peer-to-peer communications face the problem of NAT and firewalls
which do not allow peers on the internet to directly communicate with each
other.
Traditionally, peer-to-peer applications first of all require performing a discovery
for each peer to detect the behaviour of the NAT behind which the peer / host
lies. This discovery can be blocked by firewalls. The firewalls in question allow
outgoing UDP packets but block incoming NAT UDP packets. Using TCP
detection of symmetric NAT is not straightforward because a peer cannot send
message to different host after connecting to one host.
Hence, such peers cannot be reached because the details of their NAT / firewall
configuration and behaviour are not known to anybody in the outside public
network. Also more than one third party servers are required for this discovery.
The present invention also allows such peers behind such restrictive firewalls
(including ingress firewalls that can block both incoming UDP as well as TCP
packets) / NAT to be reachable from any other peer (behind any NAT, firewall
configuration (including firewalls that block outgoing (UDP) packets but excluding

21
the case of symmetric NAT) using just one central server on the public internet.
Also the load and performance requirements of this server would be greatly
reduced as compared to servers used in other inventions (which relay data or
connection request).
The invention also provides a method which will allow direct communication
between two peers separated by egress firewalls and with the same NAT
configurations as mentioned above.
In the present invention this discovery process is replaced with a simple
connection making process to the central server by the peer (which is behind
NAT and firewall) which wants to be reachable from the external internet. Thus,
the method of the invention is able to work without discovering and classifying
the NAT. The peers sends a UDP packet and waits for reply. If no reply is
obtained it makes a TCP connection with the server.
Upon completion of the connection, it sends consecutive UDP / TCP data packets
to the server at regular intervals (which will be lesser than the duration of
minimum NAT mapping). After receiving both these packets the server will reply
back to acknowledge the completion of the consecutive operations.

22
The interval will be increased gradually till the point a reply is not received from
the server. This procedure will allow to estimate the NAT mapping duration. If
the same cannot be found (say e.g. if the outgoing UDP packets are blocked), a
minimum of two minute will be chosen.
"Reachable" means that the system (which is behind any kind of NAT, firewall
including symmetric NAT but excluding firewall that blocks both outgoing UDP
packets) can receive media data packets / data packets directly from any other
system / host on the internet (behind any NAT, firewall except symmetric
NAT and firewalls that block both UDP and TCP packets).
Now for traditional applications depending upon the configuration logic has to be
built on at the server end to facilitate peer-to-peer connection between peers
separated by different types of NAT. Example the server will behave in a
different manner for connecting symmetric NAT with cone NAT; and connecting
Peers behind two cone NAT. Also the method for connection will be different
based on the type of NAT in between. In some cases some dedicated relays are
needed in addition to the central server. These act as intermediaries to send
data to peers behind symmetric NAT. In other cases these applications simply
relay the real-time media data traffic between the two peers the relay thereby
becoming a bottleneck for the communication.

23
This is, however, not efficient and the method of the invention displaces any
need for such relays or any other dedicated hardware either at the peers or ISP
or internet or at any places except just a central server which maintains state
information for the peers.
The present invention eliminates all this to provide a method and a system which
allows the simplification of this central server and the connection making
procedure (any actions after which the two clients may interact directly and more
specifically the peer initiating the request may send the packets directly to its
desired target) between the clients the same irrespective of the kinds of NAT in
between. A method wherein the peers as well as the central server does not
have to bother about which type of NAT a peer is behind thereby eliminating the
need for discovery process which relies on more than one third-party servers.
The present invention provides a single method which can allow a peer which is
behind any kind of NAT and firewall configuration (except firewalls that block
both outgoing UDP and TCP packets) to be reached by any other peer behind
any NAT, firewall configuration (except firewalls which block both the outgoing
UDP and TCP packets and do not forward fragmented packets).

24
Whenever either of these systems tries to inform the other or send media / data
packets to it directly, the same can be done using the same procedure by
querying just one central server.
Traditionally, forwarding data packets (for streaming, VOIP, gaming, inventory
control etc.) inside symmetric NAT or to a host which is behind any kind of NAT
and firewall with from outside was not possible without external relays or
rendezvous service. Also firewall could block incoming packets.
These two are the failure cases that can be found out by communicating with
STUN servers. Most current techniques are unable to do media streaming on a
peer-to-peer basis under these circumstances.
Further, if the two NAT's are symmetric and the hosts behind these are also
behind firewalls that block the discovery process, it will not be possible with the
existing art to traverse these NAT's because the appropriate method would not
be able to be selected.
Now even if discovery process succeeds, but both the peers are behind
symmetric NAT's and some other types or firewalls, there is no existing method
which allows direct peer-to-peer communication between the peers without port-

25
forwarding, relaying, rendezvous service (as in skype) etc. The same becomes
possible with the method of the invention.
Even when the peers are not separated by symmetric NAT but are protected by
firewalls that block spoofing of IP then some of the existing art (which rely on
spoofing) fail but the method presented in the present invention.
Infact, the firewall can be configured to block protocols like RTP, RTSP, and
RTCP which convey real time data traffic over UDP or may be configured to
simply block any incoming UDP packets.
Now if a peer wants to contact other peer then many existing art require relaying
of this request to the other peer through some central public server, without
which the two, would not be able to communicate. The other peer then opens
up a NAT mapping through which the first peer can send data packets. Thus the
connection request is relayed.
This relaying of connection request is not required as per the method of the
invention. One peer can directly contact the other without relaying of request.
Now the invention also offers the option to the first peer to block any incoming
traffic from the latter. Infact, the first peer described above can be setup as a
multi-casting server sending pre-scheduled data traffic to its clients or upon

26
initiation by one client to all the registered clients. In such a scenario this
feature of uni-directional communication from the server acts as a security
feature so that the server may not be the target of DOS attacks or other attacks
from rogue clients.
Also as per all the existing art, no method exists which allows a host behind NAT
to connect to multiple clients outside of its NAT over the public network or
behind some other NAT with just one NAT mapping / session / hole. This big
advantage of the current invention allows configuring a host behind NAT's
(through which many other private hosts also access internet) as a server
capable of real time communications with large number of clients simultaneously.
Further the server is highly secured because it can block any incoming data or it
can send data to its clients in such a manner that they are unable to identify its
identity, the identity of the host configured as a server (which is behind NAT's,
firewall). Without knowing the end-point identity even those clients who receive
data from the server (private host configured as server) may not be able to
revert back to it.
Thus, the method provides for such secure and configurable connections
between the end-points wherein one end-point may send, receive or just send

27
data or just receive data to the other end-point and may choose which
mechanism to follow.
All other existing art allow for just a bi-directional channel through which the
peers interact. So if peer A sends message to peer B and peer B receives it then,
peer B can also send a message to peer A. But the current invention secures
this by allowing peer A to send a message to peer B in such a manner such that
its identity is not disclosed and that B may not be able to send a message to it.
Also the NAT mappings required by one host behind NAT's to communicate with
a large number of public and private hosts is either just one. For some cases of
NAT which do not forward fragmented packets, the host requires one NAT
session to communicate with different hosts and one mapping to communicate
with each private host which is still better as compared with all existing art which
require a new mapping to connect with each new client or to change / overwrite
a previous mapping (thus breaking an old connection).
In fact, this will greatly ease direct peer-to-peer communication and allow rapid
deployment of peer-to-peer protocols.
The invention allows host behind NAT to be configured as a server accessible on
the internet and enable it with the remote wake up feature; according to which

28
any remote client / host may be able to wake it up as required. This was not
possible for hosts using private internet protocol unit the present invention. This
is because most wake up technologies work on local area network (LAN) only or
require the knowledge of the internet protocol address (of the host or its
external internet protocol, i.e. the external internet protocol of its NAT). But the
hosts behind NAT have internet protocol addresses such that packets addressed
to those internet protocol addresses and sent from the public internet or from
inside another NAT will not reach hosts. This idea is not implemented in any of
the existing products and no patent comes out with a method to solve this.
This is the traditional NAT problem which imposes the limitation that to receive
any data packets, a host behind NAT is required to have a NAT mapping.
The present invention provides some methods to keep alive such mapping the
host must itself be awake or must use some sort of a fake packet sending device
to keep alive the NAT mapping on its behalf. This hardware will be an additional
cost and keeping a permanent mapping will be a constraint on NAT resources,
which will not allow any future connections for other hosts inside it. In case of
resource crunch it may even drop old mappings, in which case the mapping kept
alive by the fake sender will be destroyed and a new one may get generated, i.e.
the external end-point of the mapping may get changed. In this case

29
remotewakeup of the host behind NAT's will not be possible. In the former case,
other hosts inside NAT's will be unable to communicate with any external host.
To accomplish this, every host behind NAT using the method of the invention
shall register its connection details (internal internet protocol, ports; external
internet protocol, ports; mac address, wake up patterns supported, router's mac
address, link layer details, open NAT mappings, first-hop router internet protocol,
mac address, whether its gateway is UpnP / MIDCOM enabled or may allow
permanent port-forwarding etc.) with the central public server. If host reports
that port forwarding is possible. The server records the port details. The client
reports forwarded ports, the server establishes the validity of the same, by
contacting the client using these. If found valid, the server shall store these as
wake up end-points for the host.
Now any client which logs in and request connection with the host mentioned
above, shall be provided with the wake up end-point information, the external
internet protocol, port information using which a wake up packet can be sent to
it.
If the client reported ports are not valid then the server provides the client with a
list of all hosts which have the same external internet protocol. The host sends
out request using the forwarded ports to all such hosts, all hosts that receive

30
such message from it, report to the central server. This request contains the
peer name of the host along with the wake up packet details.
All such hosts update the wake-up end point information for this host. The
server marks all such systems as being candidate wake up end - points for the
system.
The central server will then look-up and send a list of all the hosts which have
reported the same external internet protocol or not. The host will then send
requests to these, host (reported by the server) and will find out whether they
are outside of its realm or not. If none is within its realm, then the system will
not go into stand-by (taking exception for the case of port-forwarding), if any
one is within its realm then the system is allowed to go into sleep. The other
case in which a host is not allowed to go into suspend state is the case when it is
the wake up end point for another host and all other wake up end-points for
such a host have gone into suspend or have logged out or unavailable.
Before going into sleep it informs the central server about its power state.
Whenever any other system wishes to contact this host, the server then sends a
wake up request to any host that is alive using a special format. This wake up
request contains the details required to form a wakeup packet and details
regarding the destination system and its NAT. The wake up packet shall be

31
formed by this system and forwarded to the appropriate host which is to be
woken up. The host upon waking up notifies the central server which stops
sending wake up requests to it and provides the other client with the information
necessary for direct peer-to-peer connection as per the method described in the
operation of the invention. In case the host has public internet protocol, then it
can be woken up directly by any client.
The known system is for NAT and firewall traversal, but it uses TCP and is not for
real time streaming. The purpose of the present invention is to allow direct
peer-to-peer real time media streaming.
The present method shall fool the firewall and pass the real time data traffic
across symmetric NAT. The central server used for this purpose (in the method)
has no timing constraints and any variable (but reasonable) amount of delay
between the central server and peer can be accommodated and shall not result
in failed connection attempt. This is because the server does not play any role
while the NAT has actually traversed by packets from one peer to the other peer.
The server merely exchanges certain information with the clients.
The central server plays no role while NAT is being punched through and does
not require to co-ordinate between the peers while creation of the connection.

32
The section below describes some of the advantages of the present invention
over known systems.
Traversal of symmetric NAT is possible in the present method as well as traversal
of firewall (at least some which can block some existing techniques).
Traversal of the above is possible without requiring dedicated relays or dedicated
hardware or software at the ISPs end or requiring configuration of the same.
The invention requires no additional hardware than the two servers needed for
initiating the connection.
The method is for initiating peer-to-peer communication.
Information required at the central server for the peers. The invention provides
a method for traversal which requires minimum of network address translator
resources to connect to a number of clients.
Another advantage of the method is its ability to connect large number of clients
simultaneously with just single network address translator session.
The inventive method is for network address translator traversal without
discovery of network address translator characteristics at both end-points and
without the need for even network address translator discovery at one of the

33
end-points (which will listen for connection request or behave like a receiver
waiting for multiple systems to send data to it).
The invention provides a method for peer to peer communication by traversal of
symmetric network address translators and firewalls at both end-points
without requiring port-forwarding, relays, proxies, gateways, dedicated
hardware, any new network infrastructure or devices, or requiring changes to
any existing network infrastructure or software on top of the same.
The invention further provides a method which allows large number of hosts
(both on the public internet as well as hosts behind some network address
translator, firewall to connect to a peer behind symmetric network address
translator (all kinds of network address translator and specified firewalls in this
document) with the peer having just one network address translator mapping,
thus allowing it be behave as a server. Such a scenario is not possible with all of
the existing art. And for the same reason we do not see personal computers in a
person's home having the ability to stream to multiple clients as a multi-casting
server. Such applications will become very feasible by the method of the
invention.
Server to maintain peer information and to initiate direct peer-to-peer
communication by facilitating opening bi-direction communication channels. The

34
server maintains information regarding the peers, their names, passwords, and
authentication details IPs (external, internal).
Method to initiate connection between peers by the peer which wants to initiate
the connection). Which would be used by the peers behind NAT and firewall.
A host which is in the listening mode, and can be behind any NAT or multiple
combinations of NAT and all those firewalls that do not block both outgoing TCP
and UDP packets). This host can either be a receiver of real time data from
multiple hosts on the internet or it can be configured as a server in which case it
can receive connection requests for streaming real time data / communication
from multiple hosts on the internet and will then be able to communicate with
each one of the multiple hosts separately as per their request.
Further the system mentioned above implements a filter hook driver to capture
all ICMP packets received by the hosts (including fragmented packets). Along
with this it implements layers on top of this driver which have the duty to identify
which of the captured packets / fragments are required by which application.
This module parses the information present in the ICMP packet and forwards it
to the application by passing any other IP protocol processing by the TCP / IP
stack already present on the system. This module not only passes the desired
information to the desired application but also informs the application which

35
client sent that packet. This information is encapsulated in the data sent to the
application so that application may identify the source as well as the details
identify to what real-time communication the packet belongs. This is because
the same application may be able to perform multiple real-time communications
with separate real-time streams from each of these sources which are
independent of each other. Example a host may receive media streams from
multiple servers on the public internet. The host shall identify which media
stream has some from which source using this information.
The actual procedure or method of the present invention that needs to be
implemented at both the end-points is given below:
A transmitter or a system which seeks to receive media data from another peer
on the internet (which has been described above). This host can be behind any
NAT or combination of multiple NAT's and any firewall except those that block
both outgoing TCP, UDP connections and cannot be configured by the host using
protocol like SOCKS (for the same) and except those that are configured to block
both incoming UDP and TCP packets in port ranges usable by the method of the
invention.
Additional authentication data present in the communications. Further the
invention requires detecting the duration of Ant session and ICMP timeout. This

36
will be done by the peers by coordinating with the central server. All the hosts
wishing to receive data will open up such NAT mappings.
As shown in Figure 1, any peer that wants connections from outside registers
with the servers (by providing name for itself, which shall be referred to as the
peer name) and its details like, IP, external IP, ports, etc., are stored. At
registration it provides its name (peer name to be queried by any other peer),
password and required authentication parameters.
In addition the client may also find out the NAT session duration using the
method described in detailed description.
It opens up a NAT mapping to the central server and keeps it open till the time it
wants to be reachable directly data from outside.
All the hosts wishing to receive data / communication from outside will open up
such NAT mappings.
Using this it keeps on sending packets to the server on the same port using the
same internal port to keep its mapping refreshed. This host will also be referred
to as host 1. All the details of the IP header of transport headers along with
checksum is maintained by the server for (this host) host 1 and transport.

37
Host 1 discovers the ICMP timeout duration with the aid of the central server in a
similar manner and keeps sending the same data packet to it at intervals that are
not more than the discovered ICMP timeout interval. This interval is the time
after which incoming ICMP packets (for error with packets sent out using the
current NAT session as stated above) will get discarded by NAT.
In the second step, any peer wishing to connect to other peer may do so by
querying the central server for the peer name it wants to connect to. For this it
connects with the server sending its IP, the server replies back with the IP it sees
on packet. The client can hence know whether it is behind NAT or not.
If not then, it first has to authenticate itself to the server by providing the details
as are required to connect to a particular client / receiver. The server forwards it
those details. This host will be also referred peer 2 in the following text of this
section.
If peer 2 is not behind NAT as it discovered in the second step, procedure as in
step 3 and 4 is followed else if it is behind NAT procedure in step 5 and following
steps is followed.

38
In the third step the peer 2, wishing to send data / connection request to host
behind NAT in listening / receiving mode, will then craft an ICMP error packet.
The details of the encapsulated IP header; supposedly of the packet that
generated the error, had been taken from the server earlier.
Now if the peer is behind a NAT as decided in step 2, then ICMP packet's source
and destination address and IP addresses and ports in the encapsulated error
packet header are as follows:
On the IP header the source IP = same as itself i.e. IP to peer 2. The
destination IP = external IP of the NAT behind which the host to be contacted
lies.
On the ICMP error packet, in the IP header + 8 bytes section the following will
be the IP addresses and transport level entries):
Source IP = external IP (of host 1) of the NAT behind which the host to be
contacted lies.
Source port = external port of the host behind NAT which is to be contacted, as
observed by the central server on the connection / data packets it received from
the former (host behind NAT to be contacted).

39
The central server reported this port to the peer which wants to initiate the
connection upto being queried by it in step 2.
Destination IP = IP of the central server
Destination port = port on which central server received packets from the host
behind NAT is to be contacted.
The destination port will be the port on the server to which the client behind NAT
has sent packets earlier in step 1, The source port will be the same as that of
the port on which the central server received packets from host 1.
This packet will be forwarded by NAT and firewall because a state mapping
exists for the connection of host 1 to central server on which the error packet is
sent. Hence, the NAT forwards it and the firewall also allows it.
The part after the ICMP portion contains the data. Thus, an IP packet
encapsulates both ICMP packet (with the encapsulated error packet details) and
the real time communication data along with identification details and NAT
session details of the sending host.
Direct configuration of IP details such as these is allowed in latest version of
windows (e.g. XP SP2) which support sending and receiving of raw ICMP packets
for all kinds of connections without requiring kernel level access or usage of
drivers.

40
The peer 2 will now send this packet (as described above) to the external IP of
outermost NAT behind which host 1 lies which it found out from the central
server. This packet will reach the client and contains authentication details
regarding the client and details regarding the port it can use for listen for
incoming connection request from the client along with the media data. This
packet also contains the IP, port external IP and peer name of peer 2. Now,
peer 2 can keep sending the data by appending the data after the IP header + 8
bytes section in the ICMP packet. The host 1 may contact it back on ports it has
sent for receiving up control packets or making other connections or any other
data. This will contain information regarding the media source (which would be
unique amongst all hosts on the internet) and data identification ID to identify
which real-time communication this packet pertains to.
Peer 1 also sends the details regarding its connection with the central server in
this packet; host 1 can use this to communicate back with peer 2 by crafting
ICMP in a similar manner as used by peer 2 above (but does not require to
contact the central server for these as is done by peer 2 above).
Procedure used by peer 2 to contact host 1 (if peer 2 is also behind NAT).

41
In this case, peer 2 crafts an ICMP error packet (of any type which is forwarded
by NAT e.g. destination host unreachable).
The details for the same are as follows:
IP header of the ICMP packet:
Source IP: Internal IP of peer 2
Destination IP: external IP of host 1 as communicated by central server.
Protocol: ICMP type: Destination unreachable (any code); infact any ICMP error
type or code can be used except echo request / reply.
ICMP section (IP addresses and ports in encapsulated IP header + 8 bytes
section of ICMP error packet
Source IP: Internal port on peer 2 had sent a UDP packet to host 1 in the last
step.
Destination IP = external IP of host 1.
Destination port = external port used by host l's NAT for sending its packets to
the central server.
The peer 2 will send this packet in fragments such that the part of the ICMP
packet, following the ICMP MTU-size section i.e. starting from the section

42
containing the error packets details (IP header + following 8 bytes) of the
"virtual" data packet (for which the error packet has been sent) will be sent first.
This will also contain the media data and identification details of peer 2 using
which host 1 may contact it back. The last fragment sent would be the starting
of the ICMP packet till the IP details section and will just contain the type, code
of the packet along with MTU size.
This packet will be collected by the receiving NAT and forward to host 2 which
can contact peer 1 back using the same method.
Now an ICMP error message is crafted by peer 2 and sent to host l's external IP.
Addresses in IP header:
Source IP: IP of peer 2.
Destination IP: External IP of host 1.
ICMP section (IP addresses and ports in encapsulated IP header + 8 bytes
section of ICMP error packet)
Source IP: external IP of host 1.
Source port: external source port used by host l's NAT to forward UDP / TCP
packets from host 1 to the central server packets (as described in step 1).

43
Destination IP: external IP of peer 2 (which it had discovered from the central
server).
If the above procedure fails, peer 2 request central server to relay a connection
request to host 1. Then the central server requests host 1 to send a packet to
the external IP of peer 2's NAT at a particular port on which peer 2 is sending
packets to the central sever. The peer 2 then crafts the following the ICMP
packets and sends it to the external IP and external port on which host 1 was
sending packets to the central server.
IP address port details in encapsulated packet IP header section of ICMP packet.
Source IP: External IP of host 1.
Source port: External port on which Host 1 sends packets to the central server
(as observed by the central server).
Destination IP: Its own IP.
Destination port: The source port using which it sent a data packet to the host 1
at host l's external port (on which host 1 contacts the central server).
The size of the IP packet is kept more than is required for the ICMP section. The
data and communication parameters to be sent are appended after the ICMP
section. The host 1 upon receiving this packet responds back to peer 2 in a

44
similar manner without contacting the central server because it already has the
details required to contact peer 2 in the ICMP packet sent to peer 1.
Thus, any kind of connection is possible, i.e. one which is bi-directional in which
both peers send packets to each other, or uni-directional in which only one end
may be able to send the packets to the other but packets from the latter will be
blocked from reaching the former.
For further details please refer the detailed description (this would compare the
current method with existing art at each step).
Effects / Advantages of the invention
Facilitates proper peer to peer communication between peers.
Allows a host behind NAT and restrictive firewalls to perform real-time
communications with a large number of hosts outside of its NAT simultaneously
without monopolizing on NAT resources or over-extending on NAT resources.
Thus, such a system can be setup as a server accessible by large number of
clients for real time media streaming or other real-time communications.
Eliminates NAT discovery process and the multiple third part servers that are
required. The maintenance costs of these are saved.

45
Simplifies the connection making logic at the central server; infact the same
method applies to almost all kinds of NAT, firewall configurations. So the server
has to perform the same steps to allow any kinds of peers to communicate.
Traverses both ingress and egress firewalls, all kinds of NAT at the receiver end
and all kinds of NAT except symmetric NAT at the sender end without reversal of
connection. Some current applications require connection reversal wherein the
client behind symmetric NAT has to initiate the connection always. So the
central server has to identify which one is behind symmetric NAT and will have to
adjust the connection making process such that even though a peer wants to
send the data to client behind symmetric NAT but even then it must wait and
listen for the client behind symmetric NAT to initiate the connection. Thus, it
allows peer to peer communication without connection reversal thereby making it
more suitable for multi-casting from one peer behind NAT / firewall etc to a
number of different peers also behind NAT, firewall etc. The method uses just
one server and no relays, other hardware installations anywhere, thereby saving
lots of costs. Proposes a single method which can be used to initiate
communication between peers across wide variety of NAT, firewall configuration.
Proposes a method which simplifies the connection making process between any
two peers and which can be extended to provide a very simple interface to

46
applications that have to perform multi-casting (here a server cannot try to find
out about the NAT behaviour of all the clients eligible for multi-cast).
Very suitable for multi-casting requirements (currently a server cannot send
multi-cast to all kinds of clients behind a variety of NAT, firewall configurations
because currently no single method can perform NAT traversal so for each client
different approach is needed and hence another public server or relay is need to
mediate the communication process between the server and the clients).
The invention thus allows multi-casting from private system to other private
system and that too despite firewalls, different kinds of NAT.
Allows client behind symmetric NAT to be reached directly by the other peer and
not through a public server or relay (for this the other peer simply has to get
certain information regarding the client behind NAT, firewall and using the
method of the invention can directly communicate with the other peer without
any intermediate relay or without being first by the client behind symmetric NAT
as in RTP).
Another big advantage being that the host behind NAT can be configured as a
server accessible on the internet and will have the remote wake up feature;
according to which any remote client / host may be able to wake it up as

47
required. This was not possible for hosts using private IP until the present
invention. This is because most wake up technologies work on LAN only or
require the knowledge of the IP address (of the host or its external IP, i.e the
external IP of its NAT). But the hosts behind NAT have IP addresses such that
packets addressed to those IP addresses and sent from the public internet or
from inside another NAT will not reach hosts. This idea is not implemented in
any of the existing products and no patent comes out with a method to solve
this.
This is the traditional NAT problem which imposes the limitation that to receive
any data packets, a host behind NAT is required to have a NAT mapping. We
have some methods to keep alive such mapping the host must itself be awake or
must use some sort of a fake packet sending device to keep alive the NAT
mapping on its behalf. This hardware will be an additional cost and keeping a
permanent mapping will be a constraint on NAT resources, which will not allow
any future connections for other hosts inside it. In case or resource crunch it
may even drop old mappings, in which case the mapping kept alive by the fake
sender will be destroyed and a new one may get generated, i.e. the external
end-point of the mapping may get changed. In this case remote wakeup of the
host behind NAT will not be possible. In the former case, other hosts inside NAT
will be unable to communicate with any external host.

48
The present invention thus provides idea and method for traversal of symmetric
NAT's without relays or rendezvous service (as in skype) or any external
dedicated hardware or software installed on any other system (other than the
peers.
The methods described above also support traversal of cone and restricted NAT's
traversal of firewalls (some types which do not block outgoing UDP packets
based on ports but block incoming UDP packets from outside) is also possible.
The methods initiate and accomplish remote wake up of a peer behind NAT by
other peer behind NAT.
The method can initiate the remote wake up of a suspended (sleeping) remote
peer behind NAT for establishing media streaming between the two. The
method for initiating remote wake up as mentioned above is such that the
success or failure of the same is known to the peer initiating the wake up of
suspended peer.
The method as mentioned above, works across NAT which is not just the first-
hop NAT but may be present on any hop. (NAT may not be multi-kevel).

49
The invention provides methods for all the above which do not require making
any static port mappings on NAT device and method for NAT traversal which
does not require a separate relay server to transfer data packets between the
peers in the cases as above.
The method of present invention provides NAT traversal required to sustain peer-
to-peer communication after the first peer-to-peer data transfer has occurred.
The method does not require any third party server for intermediate data
storage. Example some applications may upload the data to a central server
from where the file can be streamed to the other client. The method can be
used for NAT traversal for real time media streaming.
The method as mentioned above does not require any change of protocols or
infrastructure at the ISP. The method does not require application level
gateways or dedicated hardware any where from peer to ISP or ISP to peer.
The role of the central server is merely transfer of necessary data between the
clients and the server has no timing or synchronization job, i.e. transferring of
connection request at one end to the other for getting the NAT mappings at the
other end (where the first client / peer can send message to open up his NAT.

50
The invention provides a single method which can facilitate peer-to-peer
communication across a UPNP NAT, a full cone NAT, a restricted cone NAT, a
symmetric NAT with ISA functionality, a symmetric NAT with deterministic port
assignment, a generic symmetric NAT or any other NAT and any firewall with
ingress traffic filtering as well as egress traffic filtering (which can block spoofed
traffic, i.e. both NAT and firewall may be present.
The method does not require rely server as is required in some cases of NAT
traversal as mentioned in the existing patents or technologies.
The invention provides a method where no additional hardware (e.g. a server /
relay inside NAT or a common controllable NAT or some DNS ALG server,
gateway or tunneling, proxy device etc. external to peers are required to be
embedded additionally within peers) or software such as an application level
gateway is required to be system installed on any machine other than the peers.
The only hardware required is a central global server with global IP in public
address space.
Delays at the central registration server (which can be the only one that is
required for the method) in sending information to peer (which is requesting
connection) for connection initiation do not have any upper bound which if

51
exceeded beyond this limit; may cause the connection making process (between
the peers) to fail.
The central server (registration server) used in the invention does not act from
the point, the connection attempt has started from one client (which initiated the
connection by requesting the central server to give information to connect it to
the other peer which has been registered which the server) to the point that
media data packet has actually reached the other client (after crossing its NAT).
A method which does not involve or require IP or MAC spoofing. A method
which will work if any or both peers are behind routers capable of reverse path
filtering (RPF).
The method for symmetric NAT traversal as described above is deterministic and
not probabilistic. The method is not as fragile or dependent on synchronization
or specifics NAT device or some characteristics (which are used by well-known
methods like port prediction) which may not be generic like port or address
sensitivity and hence is extensible to devices not following common behaviour for
these characteristics.
The system does not require third party address-and-port discovery servers to
ascertain the nature and port-mapping metrics of a given client's firewall / NAT

52
and requires only one central server (which is not third party) to start the direct
communication between peers.
The system and method completely eliminates the need of discovery and
characterization of any of the NAT's or firewalls which obscure any of the
connection end-points and a method which requires just one central server to
initiate communication between the peers behind such NAT's and firewalls. All
these can be done without port forwarding, relaying or proxy services. The
receiver (which can be behind the client behind symmetric NAT or any firewall
that blocks the incoming UDP packets) will not be required to be informed by the
central server to start the communication with any host outside of its NAT i.e.
any client outside wishing to send data to this client may do so without first
receiving data from this client (or the receiver which is behind symmetric NAT).
The method does not overburden the resources of NAT by creating too many
NAT mappings and is unaffected by NAT mappings from other internal end-
points of the timing of their NAT mapping. The method accomplishes NAT
traversal without knowing whether the receiver or transmitter is behind a NAT
and which does not require knowledge of the NAT behaviour and characteristics
to classify the NAT (as cone or symmetric or any other type) and choose a
behaviour but one which works for all combinations of NAT and firewall as
specified in this document (i.e. any NAT at the receiver end; and NAT except

53
symmetric NAT which cannot be port forwarded from the peer; any firewall
including ingress and egress traffic filtering capable of blocking spoofed
outbound traffic ones except the one which blocks both outgoing TCP, UDP
packets).
The traversal of firewall, works across all firewalls categorized the description
and does not rely on a specific firewall traversal protocol like SOCKS. Discovery
and characterization of NAT at the receiver end is not necessary and for the host
wishing to translate only discovery of NAT is necessary which requires just one
central server and simple connection making from the host to the public server.
The method of the present invention for NAT traversal allows a client / peer
behind NAT (all kinds including symmetric NAT), firewall (all kinds, even those
that block spoofed traffic; except those that configured to block all outgoing UDP
and TCP packets) to communicate (receive real-time data) with multiple hosts
(public as well as private) outside with just one NAT mapping. Thus, a client
behind NAT may talk with more hosts outside of its NAT than is possible. This is
because a NAT can only assign a limited number of mappings. So if a lot of
hosts on the internet have to communicate with a client behind symmetric NAT,
then the NAT may run out of assignable external ports and the internal client
may not be able to communicate with other hosts on the internet. Example if an
internal client decides to talk to 100 k clients then it cannot do so and further if

54
one client has to talk to more than 30 k hosts outside then the NAT may allow
only to such systems. These systems may monopolize the NAT resources.
Hence the invention presents a method using which a client behind any NAT may
communicate with large number of external hosts without monopolizing on the
NAT resources and with just one NAT session.
The method as described above works for multiple NAT's also. The method
allows both uni-directional communication between the peers as well as bi-
directional depending upon the peer which initiates communication with the
other peer.
Thus, as per the method, a peer may be able to contact (send data packets) the
other peer in such a manner that the latter may not be able to send data packets
to it or may also contact the other peer such that it can receive replies back from
it. Thus, enhancing the security here any rogue host may not simply act.
For this it has to open a NAT session with the server and while connecting it
should provide the details regarding the same the same to the other peer. Using
these details, the other peer may directly reach it back. Thus, if a peer is
configured as a server it may contact its clients in such a manner that some of
them who may be suspect or unreliable may not contact it back.

55
The method allows a host behind NAT (any) and restrictive firewall to be
configured as a server capable of streaming media / data in real time to clients
which can be both public as well as private. It is observed very commonly that
certain rogue systems may be able to pose as target servers to which a client
whishes to contact and may use this to gather data / information which is private
to the client. In a similar manner it may send incorrect data to the client.
As per the method of the invention the client hands over certain details to the
actual server without which none in between on the internet can mislead either
of these systems. The method allows configuration of a server which can send
media-streams on its own schedules to its selected clients without being
requested. Further, the method allows such a server (self-initiating) to stream to
multiple clients with only selected clients being able to revert back. This gives
the security to such servers against the common DOS attacks.

56
WE CLAIM
1. A method for firewall and NAT traversal for establishing secure direct
peer-to-peer real-time communication between a host and at least
another host 2, comprising the steps of:
- host 1 requesting a global server for details on host 2 to be
contacted, and for determining that the NAT of host 2 may receive
communication out of order;
- crafting a fragmented ICMP error packet from the details obtained
from said global server; and
- sending sequentially all fragments of said error packet to the NAT
of host 2.

2. The method as claimed in claim 1, wherein said global server determines
that the NAT of host 2 can receive communication out of order when said
host 2 registers with the global server.
3. The method as claimed in claim 1, wherein host 2 is notified of the
request of host 1 when the global server fails to determine if host 2 can

57
receive communication; host 2 then sends UDP / TCP packets to host 1
through the server; and a non fragmented ICMP packet is then sent to
host 2.
4. The method as claimed in claim 1, wherein said NAT comprises symmetric
as well as all other types of NAT like cone or restricted NAT's and said
method allows communication between the two hosts both being behind
the NAT'S.
5. The method as claimed in claim 1, wherein said firewalls can be all kinds
of firewalls, ingress and egress, like the ones that block spoofed traffic,
excepting those that are configured to block all outgoing UDP and TCP
packets.
6. The method as claimed in claim 1, wherein both hosts can be behind
multiple layers of NAT.
7. The method as claimed in claim 1, wherein a host behind any NAT may
communicate with a large number of external hosts during one NAT
session, without monopolizing on the NAT resources.

58
8. The method as claimed in claim 1, wherein said communication between
hosts may be media streaming or voice on internet protocol (VOIP).
9. The method as claimed in claim 1, wherein establishing said
communication between host/s may be for initiating and accomplishing
remote wakeup of hosts behind NAT by another host behind NAT.
10.The method as claimed in claim 7, wherein a remote wakeup of a
suspended (sleeping) remote host behind NAT can be initiated for
establishing media streaming between the two.
11. The method as claimed in claim 8, wherein the success or failure of said
initiation of remote wakeup is known to the host initiating the wakeup of
the suspended host.
12. A method of Network Communication wherein one peer initiating
communication may keep itself hidden from its other peer , in such a
manner that the latter may not able to send any data/communication to
the former even after receiving data packets from the former.

59
13. A method for firewall and NAT traversal for establishing secure direct
peer-to-peer real-time communication between a host and at least
another host 2, substantially as herein described and illustrated in the
accompanying drawings.
Dated this 23rd day of November 2007.

One object of the present invention is to remove hardware and software
dependencies for solving network address translator and firewall traversal
problem and allowing direct peer-to-peer communication across all classes
(classified on the type of end-point connectivity supported i.e. the type of
address-port translation) of network address translators (including all types of
symmetric NAT, port restricted cone NAT and so on) and firewalls (as described
above and in the pages to follow) which block other network address translator
traversal methods, thus allowing direct reachability of client behind symmetric
network address translator.

10
Another object of the invention is to provide a single method for network address
translator, firewall traversal which works for almost all kinds of firewall, network
address translator configurations at both the end-points.
This will allow a client behind network address translator and firewall to maintain
direct peer-to-peer connectivity with large number of hosts outside of the
network address translator, all at the same time, for long durations without
monopolizing on network address translator resources or disrupting the
connectivity of other hosts behind the same network address translator with the
internet because of the same. The invention is hence a method for establishing
direct peer-to-peer communication using just one external server and makes at
most two network address translator mappings (at all the end-point network
address translators i.e. all the network address translators which obscure / hide
the end-point hosts which have to communicate directly) to connect with large
number of hosts outside.
The invention also allows a host behind network address translator to connect to
large number of public servers for real-time communications without straining on
network address translator resources or disrupting the connectivity of other hosts
behind network address translator: