CLIAMS:1. A method for performing a session based on NAT (Network Address Translator), comprising:
determining, by a sending endpoint, whether behavior of a local NAT which the sending endpoint is behind and behavior of a remote NAT which a receiving endpoint is behind are a symmetric NAT;
performing, by the sending endpoint with the receiving endpoint, a session over a relay to relay candidate pair, upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT; wherein the relay to relay candidate pair is a relay candidate addresses pair allocated from a Traversal Using Relay NAT (TURN) server to the sending endpoint and the receiving endpoint.

2. The method as claimed in claim 1, wherein determining, by a sending endpoint, whether behavior of a local NAT which the sending endpoint is behind and behavior of a remote NAT which a receiving endpoint is behind are a symmetric NAT comprises:
determining, by the sending endpoint, whether the behavior of the local NAT is a symmetric NAT by querying a TURN server; and
determining, by the sending endpoint, whether the behavior of the remote NAT is a symmetric NAT by querying the TURN server or being informed by the receiving endpoint.

3. The method as claimed in claim 2, wherein the step of determining, by the sending endpoint, whether the behavior of the local NAT is a symmetric NAT by querying a TURN server comprises:
creating and sending, by the sending endpoint, an allocate request message to the TURN server;
receiving, by the sending endpoint, an allocate response message from the TURN server; wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the allocate response message; and
determining, by the sending endpoint, whether the behavior of the local NAT is a symmetric NAT based on the LOCAL-NAT-BEHAVE-RESPONSE attribute carried in the allocate response message.

4. The method as claimed in claim 2, wherein the step of determining, by the sending endpoint, whether the behavior of the remote NAT is a symmetric NAT by querying the TURN server comprises:
creating and sending, by the sending endpoint, a permission request message to the TURN server, wherein a PEER-NAT-BEHAVE-QUERY attribute is carried in the permission request message;
receiving, by the sending endpoint, a permission response message from the TURN server, wherein a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the permission response message; and
determining, by the sending endpoint, whether the behavior of the remote NAT is a symmetric NAT according to the PEER-NAT-BEHAVE- RESPONSE attribute carried in the permission response message.

5. The method as claimed in claim 3 or 4, the method further comprises:
sending, by the sending endpoint, information of a host candidate address, a server reflexive candidate address which is a translated transport address on a public side of the NAT and a relay candidate address to the receiving endpoint, wherein the information of the host candidate address, the server reflexive candidate address and the relay candidate address is used for communicating with other receiving endpoints.

6. The method as claimed in claim 3 or 4, the method further comprises:
sending, by the sending endpoint, information of a relay candidate address to the receiving endpoint, wherein the information of a relay candidate address is used for communicating with other receiving endpoints.

7. The method as claimed in claim 2, the determining, by the sending endpoint, whether the behavior of the remote NAT is a symmetric NAT by being informed by the receiving endpoint comprises:
sending, by the sending endpoint, an invite message to the receiving endpoint, wherein the invite message indicates that the behavior of the local NAT is a symmetric NAT;
receiving, by the sending endpoint, a response message which indicates that the behavior of the remote NAT is a symmetric NAT.

8. The method as claimed in claim 1, wherein the step of performing, by the sending endpoint, a session over the relay to relay candidate pair upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT further comprises:
sending, by the sending endpoint, upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT, a Session Description Protocol(SDP) offer message including a first relay candidate address which is allocated from a TURN server to the sending endpoint, to the receiving endpoint, wherein a USE-CANDIDATE attribute is carried in the first relay candidate address so as to inform the receiving endpoint to return back a second relay candidate address which is allocated from the TURN server to the receiving endpoint;
receiving, by the sending endpoint, an SDP answer message including the second relay candidate address from the receiving endpoint;
performing, by the sending endpoint, the session with the receiving endpoint by using the first relay candidate address and the second relay candidate address, wherein the relay to relay candidate pair includes the first relay candidate address and the second relay candidate address.

9. A method for performing a session based on NAT, comprising:
informing, by a receiving endpoint, information which indicates that whether behavior of a remote NAT which the receiving endpoint is behind is a symmetric NAT or not to a sending endpoint or a TURN server;
performing, by the receiving endpoint, a session with the sending endpoint over a relay to relay candidate pair upon determining that behavior of a local NAT which the sending endpoint is behind and the behavior of the remote NAT are a symmetric NAT; wherein the relay to relay candidate pair is a relay candidate addresses pair allocated from a TURN server to the sending endpoint and the receiving endpoint.

10. The method as claimed in claim 9, the step of informing by a receiving endpoint, information which indicates that whether behavior of remote NAT is a symmetric NAT or not to a sending endpoint further comprises:
receiving, by the receiving endpoint, an invite message indicating that the behavior of the local NAT is a symmetric NAT from the sending endpoint;
sending, by the receiving endpoint, a response message indicating that the behavior of the remote NAT is a symmetric NAT to the sending endpoint.

11. The method as claimed in claim 9, wherein the performing, by the receiving endpoint, a session with the sending endpoint over a relay to relay candidate pair upon determining that behavior of a local NAT which the sending endpoint is behind and the behavior of the remote NAT are a symmetric NAT further comprises:
receiving, by the receiving endpoint, from the sending endpoint, a Session Description Protocol(SDP) offer message including a first relay candidate address which is allocated from a TURN server to the sending endpoint, wherein a USE-CANDIDATE attribute is carried in the first relay candidate address so as to inform the receiving endpoint to return back a second relay candidate address which is allocated from the TURN server to the receiving endpoint;
sending, by the receiving endpoint, an SDP answer message including the second relay candidate address to the sending endpoint;
performing, by the receiving endpoint, the session with the sending endpoint by using the first relay candidate address and the second relay candidate address.

12. A method for determining behavior of a NAT, comprising:
receiving, by a TURN server, a request message from a sending endpoint;
sending, by the TURN server, a response message to the sending endpoint, wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the response message, or a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the response message, so that the sending endpoint determines whether behavior of a local NAT which the sending endpoint is behind is a symmetric NAT or determines whether behavior of a remote NAT which a receiving endpoint is behind is a symmetric NAT based on the request message and the response message.

13. The method as claimed in claim 12, the method further comprises:
storing, by the TURN server, the behavior of the local NAT determined by an NAT Behavior Discovery device.

14. The method as claimed in claim 12, wherein the receiving, by a TURN server, a request message from a sending endpoint; and sending, by the TURN server, a response message to the sending endpoint further comprises:
receiving, by the TURN server, an allocate request message from the sending endpoint;
sending, by the TURN server, an allocate response message to the sending endpoint, wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the allocate response message, so that the sending endpoint determines the behavior of the local NAT based on the LOCAL-NAT-BEHAVE-RESPONSE attribute carried in the allocate response message from the TURN server.

15. The method as claimed in claim 12, wherein receiving, by a TURN server, a request message from a sending endpoint; and sending, by the TURN server, a response message to the sending endpoint further comprises:
receiving, by the TURN server, a permission request message from the sending endpoint, wherein a PEER-NAT-BEHAVE-QUERY attribute is carried in the permission request message;
sending, by the TURN server, a permission response message to the sending endpoint, wherein a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the permission response message, so that the sending endpoint determines the behavior of the remote NAT according to the PEER-NAT-BEHAVE-RESPONSE attribute carried in the permission response message.

16. The method as claimed in any one of claim 12-15, wherein information storied in the NAT behavior discovery device and information storied in the TURN server is refreshed at the trigger of a timer.

17.A method for determining behavior of a NAT, comprising:
receiving, by a Session Traversal Utilities for NAT (STUN) server, an STUN binding request message from an NAT Behavior Discovery device;
returning, by the STUN server, an STUN binding response message, to the NAT Behavior Discovery device, wherein a NAT address is carried in the STUN binding response message and a NAT-BEHAVE attribute is included in the NAT address, so that the NAT Behavior Discovery device can determine the behavior of the NAT.

18. A method for determining behavior of a NAT, comprising:
sending, by an NAT Behavior Discovery device, an STUN binding request message to an STUN server;
receiving, by the NAT Behavior Discovery device, an STUN binding response message from the STUN server, wherein a NAT address is carried in the STUN binding response message and a NAT-BEHAVE attribute is carried in the NAT address;
determining, by the NAT Behavior Discovery device, behavior of a local NAT which a sending endpoint is behind based on the NAT-BEHAVE attribute included in the NAT address; and
updating, by the NAT Behavior Discovery device, the behavior of the NAT, to the TRUN server.

19. The method as claimed in claim 18, wherein the method further comprises:
determining by using a remote NAT Discovery algorithm, by the NAT Behavior Discovery device, behavior of a remote NAT which a receiving endpoint is behind based on an NAT-BEHAVE attribute included in a server reflexive candidate address of the receiving endpoint, wherein the server reflexive candidate address is a translated transport address on a public side of the NAT; and
updating, by the NAT Behavior Discovery device, the behavior of the remote NAT, to the TRUN server.

20. A sending endpoint, comprising:
a memory that stores a plurality of instructions; and
a processor coupled to the memory and configured to execute the instructions to:
determine whether behavior of a local NAT which the sending endpoint is behind and behavior of a remote NAT which a receiving endpoint is behind are a symmetric NAT;
perform a session with the receiving endpoint over a relay to relay candidate pair, upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT; wherein the relay to relay candidate pair is a relay candidate addresses pair allocated from a TURN server to the sending endpoint and the receiving endpoint.

21. The sending endpoint as claimed in claim 20, wherein in the step of determining whether behavior of a local NAT which the sending endpoint is behind and behavior of a remote NAT which a receiving endpoint is behind are a symmetric NAT, the processor is further configured to determine whether the behavior of the local NAT is a symmetric NAT by querying a TURN server and determine whether the behavior of the remote NAT is a symmetric NAT by querying the TURN server or being informed by the receiving endpoint.

22. The sending endpoint as claimed in claim 21, wherein in the step of determining whether the behavior of the local NAT is a symmetric NAT by querying a TURN server, the processor is further configured to:
create and send an allocate request message to the TURN server;
receive an allocate response message from the TURN server; wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the allocate response message; and
determine whether the behavior of the local NAT is a symmetric NAT based on the LOCAL-NAT-BEHAVE-RESPONSE attribute carried in the allocate response message.

23. The sending endpoint as claimed in claim 21, wherein in the step of determining whether the behavior of the remote NAT is a symmetric NAT by querying the TURN server, the processor is further configured to:
create and send a permission request message to the TURN server, wherein a PEER-NAT-BEHAVE-QUERY attribute is carried in the permission request message;
receive a permission response message from the TURN server, wherein a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the permission response message; and
determine whether the behavior of the remote NAT is a symmetric NAT according to the PEER-NAT-BEHAVE-RESPONSE attribute carried in the permission response message.

24. The sending endpoint as claimed in claim 22 or 23, wherein the processor is further configured to:
send information of a host candidate address, a server reflexive candidate address which is a translated transport address on a public side of the NAT and a relay candidate address to the receiving endpoint, wherein the information of the host candidate address, the server reflexive candidate address and the relay candidate address is used for communicating with other receiving endpoints.

25. The sending endpoint as claimed in claim 22 or 23, wherein the processor is further configured to:
send information of a relay candidate address to the receiving endpoint, wherein the information of a relay candidate address is used for communicating with other receiving endpoints.

26. The sending endpoint as claimed in claim 21, wherein in the step of determining whether the behavior of the remote NAT is a symmetric NAT being informed by the receiving endpoint, the processor is further configured to:
send an invite message to the receiving endpoint, wherein the invite message indicates that the behavior of the local NAT is a symmetric NAT;
receive a response message which indicates that the behavior of the remote NAT is a symmetric NAT.

27. The sending endpoint as claimed in claim 20, wherein in the step of performing a session over the relay to relay candidate pair upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT, the processor is further configured to:
send, upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT, a Session Description Protocol(SDP) offer message including a first relay candidate address which is allocated from a TURN server to the sending endpoint, to the receiving endpoint, wherein a USE-CANDIDATE attribute is carried in the first relay candidate address so as to inform the receiving endpoint to return back a second relay candidate address which is allocated from the TURN server to the receiving endpoint;
receive an SDP answer message including the second relay candidate address from the receiving endpoint;
perform the session by using the first relay candidate address and the second relay candidate address, wherein the relay to relay candidate pair includes the first relay candidate address and the second relay candidate address.

28. A receiving endpoint, comprising:
a memory that stores a plurality of instructions; and
a processor coupled to the memory and configured to execute the instructions to:
inform information which indicates that whether behavior of a remote NAT which the receiving endpoint is behind is a symmetric NAT or not to a sending endpoint or a TURN server;
perform a session over a relay to relay candidate pair with the sending endpoint upon determining that behavior of a local NAT which the sending endpoint is behind and the behavior of the remote NAT are a symmetric NAT; wherein the relay to relay candidate pair is a relay candidate addresses pair allocated from a TURN server to the sending endpoint and the receiving endpoint.

29. The receiving endpoint as claimed in claim 28, wherein in the step of informing information which indicates that whether behavior of remote NAT is a symmetric NAT or not to a sending endpoint, the processor further is configured to receive an invite message indicating that the behavior of the local NAT is a symmetric NAT from the sending endpoint;
send the response message indicating that the behavior of the remote NAT is a symmetric NAT to a sending endpoint.

30. The receiving endpoint as claimed in claim 28, wherein in the step of performing a session over the relay to relay candidate pair upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT, the processor is further configured to:
receive a Session Description Protocol(SDP) offer message including a first relay candidate address which is allocated from a TURN server to the sending endpoint, wherein a USE-CANDIDATE attribute is carried in the first relay candidate address so as to inform the receiving endpoint to return back a second relay candidate address which is allocated from the TURN server to the receiving endpoint;
send an SDP answer message including the second relay candidate address to the sending endpoint;
perform the session with the sending endpoint by using the first relay candidate address and the second relay candidate address.

31. A TURN server, comprising:
a memory that stores a plurality of instructions; and
a processor coupled to the memory and configured to execute the instructions to:
receive a request message from a sending endpoint;
send a response message to the sending endpoint, wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the response message, or a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the response message, so that the sending endpoint determines whether behavior of a local NAT which the sending endpoint is behind is a symmetric NAT or determines whether behavior of a remote NAT which a receiving endpoint is behind is a symmetric NAT based on the request message and the response message.

32. The TURN server as claimed in claim 31, wherein the processor is further configured to store the behavior of the local NAT determined by an NAT Behavior Discovery device.
33. The TURN server as claimed in claim 31, wherein in the step of receiving a request message from a sending endpoint and sending a response message to the sending endpoint, the processor is further configured to:
receive an allocate request message from the sending endpoint;
send an allocate response message to the sending endpoint, wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the allocate response message, so that the sending endpoint determines the behavior of the local NAT based on the LOCAL-NAT-BEHAVE-RESPONSE attribute carried in the allocate response message from the TURN server.

34. The TURN server as claimed in claim 31, wherein in the step of receiving a request message from a sending endpoint and sending a response message to the sending endpoint, the processor is further configured to:
receive a permission request message from the sending endpoint, wherein a PEER-NAT-BEHAVE-QUERY attribute is carried in the permission request message;
send a permission response message to the sending endpoint, wherein a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the permission response message,
so that the sending endpoint determines the behavior of the remote NAT according to the PEER-NAT-BEHAVE-RESPONSE attribute carried in the permission response message.
35.An STUN, comprising:
a memory that stores a plurality of instructions; and
a processor coupled to the memory and configured to execute the instructions to:
receive an STUN binding request message from an NAT Behavior Discovery device;
return an STUN binding response message, to the NAT Behavior Discovery device, wherein a NAT address is carried in the STUN binding response message and a NAT-BEHAVE attribute is included in the NAT address, so that the NAT Behavior Discovery device can determine the behavior of the NAT.

36. An NAT Behavior Discovery device, comprising:
a memory that stores a plurality of instructions; and
a processor coupled to the memory and configured to execute the instructions to:
send an STUN binding request message to an STUN server;
receive an STUN binding response message from the STUN server, wherein a NAT address is carried in the STUN binding response message and a NAT-BEHAVE attribute is carried in the NAT address;
determine behavior of a local NAT which a sending endpoint is behind based on the NAT-BEHAVE attribute included in the NAT address; and
update the behavior of the local NAT, to the TRUN server.

37. The device as claimed in claim 36, wherein the processor is further configured to determine by using a remote NAT Discovery algorithm, behavior of a remote NAT which a receiving endpoint is behind based on an NAT-BEHAVE attribute included in a server reflexive candidate address of the receiving endpoint, wherein the server reflexive candidate address is a translated transport address on a public side of the NAT; and
update the behavior of the remote NAT, to the TRUN server.
,TagSPECI:FIELD OF THE INVENTION

This application relates to communication technology, in particular to a method and system for performing a session based on NAT (Network Address Translator.

BACKGROUND

ICE (Interactive Connectivity Establishment) is a protocol for Network Address Translator (NAT) traversal. ICE makes use of Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing an offer/answer model, such as Session Initiation Protocol (SIP). Protocols using the offer/answer model are difficult to operate through NATs. Because their purpose is to establish a flow of media packets, they tend to carry IP addresses and ports of media sources and sinks within their messages, which is known to be problematic through NAT. The protocols also seek to create a media flow directly between participants, so that there is no application layer intermediary between them. This is done to reduce media latency, decrease packet loss, and reduce the operational costs of deploying the application. However, this is difficult to accomplish through NAT.

In computer networking, NAT is the process of modifying IP address information in IP packet headers while in transit. The simplest type of NAT provides a one-to-one translation of IP addresses. This is referred to as a basic NAT. In this type of NAT, only the IP addresses, IP header checksum and any higher level checksums that include the IP address need to be changed. The rest of the packet can be left untouched.

However it is common to hide an entire IP address space, usually consisting of private IP addresses, behind a single IP address in another (usually public) address space. To avoid ambiguity in the handling of returned packets, a one-to-many NAT must alter higher level information such as TCP/UDP ports in outgoing communications and must maintain a translation table so that return packets can be correctly translated back. This is referred to a NAPT (network address and port translation) for this type of NAT.

Figure 1-4 are schematic diagrams of four different forms of NAT in the prior art. The clients in Figure 1-4 can be taken as sending endpoints.

Figure 1 is a schematic diagram of Full Cone NAT. As shown in Fig.1, once an internal address (iAddr: iPort) is mapped to an external address (eAddr: ePort), any packets from iAddr: iPort will be sent through eAddr: ePort. Any external endpoint can send packets to iAddr: iPort by sending packets to eAddr: ePort.

Figure 2 is a schematic diagram of Restricted Cone NAT. As shown in Fig.2, once an internal address (iAddr: iPort) is mapped to an external address (eAddr: ePort), any packets from iAddr: iPort will be sent through eAddr: ePort. An external host (hAddr: any) can send packets to iAddr: iPort by sending packets to eAddr: ePort only if iAddr: iPort has previously sent a packet to hAddr: any. There, "Any" means the port number doesn't matter.

Figure 3 is a schematic diagram of Port Restricted Cone NAT. As shown in Fig.3, once an internal address (iAddr: iPort) is mapped to an external address (eAddr: ePort), any packets from iAddr: iPort will be sent through eAddr: ePort. An external endpoint (hAddr: hPort) can send packets to iAddr: iPort by sending packets to eAddr: ePort only if iAddr: iPort has previously sent a packet to hAddr: hPort.

Figure 4 is a schematic diagram of Symmetric NAT.As shown in Fig.4, each request from the same internal IP address and port to a specific destination IP address and port is mapped to a unique external source IP address and port, if the same internal endpoint sends a packet even with the same source address and port but to a different destination, a different mapping is used. Only an external endpoint that receives a packet from an internal endpoint can send a packet back.

Interactive Connectivity Establishment (ICE) is a technique for NAT traversal for UDP-based media streams established by the offer/answer model. ICE is an extension to the offer/answer model, and works by including a multiplicity of IP addresses and ports in SDP offers and answers, which are then tested for connectivity by peer-to-peer connectivity checks. The IP addresses and ports included in the SDP and the connectivity checks are performed using the revised STUN specification [RFC5389], now renamed to Session Traversal Utilities for NAT. ICE also makes use of Traversal Using Relays around NAT (TURN) [RFC5766], an extension to STUN.

In a typical ICE deployment, we have two endpoints that want to communicate. They are able to communicate indirectly via some signaling protocol (such as SIP), by which they can perform an offer/answer exchange of messages. At the beginning of the ICE process, the agents are ignorant of their own topologies. In particular, they might or might not be behind a NAT. ICE allows the agents to discover enough information about their topologies to potentially find one or more paths by which they can communicate.

Figure 5 is a schematic diagram of ICE deployment environment in the piror art. The two endpoints are labeled L and R. Both L and R are behind their own respective NATs though they may not be aware of it. The type of NAT and its properties are also unknown. Agents L and R are capable of engaging in an offer/answer exchange by which they can exchange SDP messages, whose purpose is to set up a media session between L and R. Typically, this exchange will occur through a SIP server.

In addition to the agents, a SIP server and NATs, ICE is typically used in concert with STUN or TURN servers in the network. The basic idea behind ICE is as follows: each agent has a variety of candidate TRANSPORT ADDRESSES (combination of IP address and port for a particular transport protocol); it could be used to communicate with the other agent. These might include: a transport address on a directly attached network interface, a translated transport address on the public side of a NAT (a "server reflexive" address), a transport address allocated from a TURN server (a "relayed address").

Figure 6 is a flowchart of a method for session establishment based on NAT in the prior art. As shown in Fig.6, the method includes:

In step 601, in order to execute ICE, an agent has to identify all of its address candidates. A candidate is a transport address -- a combination of IP address and port for a particular transport protocol. ICE defines three types of candidates, some derived from physical or logical network interfaces, others discoverable via STUN and TURN. Naturally, one viable candidate is a transport address obtained directly from a local interface. Such a candidate is called a HOST CANDIDATE.

Next, the agent (endpoint) uses STUN or TURN to obtain additional candidates. These come in two flavors: translated addresses on the public side of a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers (RELAYED CANDIDATES). Figure 7 is a schematic diagram of the relationship between a relay candidate, a server reflexive candidate and a host candidate. As shown in Fig.7, the notation X:x means IP address X and UDP port x.

In step 602, when only STUN servers are utilized, the agent sends a STUN Binding request [RFC5389] to its STUN server. The STUN server will inform the agent of the server reflexive candidate X1':x1' by copying the source transport address of the Binding request into the Binding response.

In step 603, when the agent sends the TURN Allocate request from IP address and port X:x, the NAT will create a binding X1':x1', mapping this server reflexive candidate to the host candidate X:x. Outgoing packets sent from the host candidate will be translated by the NAT to the server reflexive candidate. Incoming packets sent to the server reflexive candidate will be translated by the NAT to the host candidate and forwarded to the agent.

The allocate request then arrives at the TURN server. The TURN server allocates a port y from its local IP address Y, and generates an Allocate response, informing the agent of this relayed candidate. The TURN server also informs the agent of the server reflexive candidate, X1':x1' by copying the source transport address of the Allocate request into the Allocate response. The TURN server acts as a packet relay, forwarding traffic between L and R. In order to send traffic to L, R sends traffic to the TURN server at Y:y, and the TURN server forwards that to X1':x1', which passes through the NAT where it is mapped to X:x and delivered to L.

In step 604, once L has gathered all of its candidates, it orders them in highest to lowest priority and sends them to R over the signaling channel.

The candidates are carried in attributes in the SDP offer. When R receives the offer, it performs the same gathering process in step 605~607, responds with its own list of candidates in step 608.

In step 610, at the end of this process, each agent has a complete list of both its candidates and its peer's candidates. It pairs them up, resulting in CANDIDATE PAIRS

In step 611~622, it is to see which pairs work, each agent schedules a series of CHECKS.

wherein, Each check is a STUN request/response transaction that the client will perform on a particular candidate pair by sending a STUN request from the local candidate to the remote candidate.

The basic principle of the connectivity checks is simple:Sort the candidate pairs in priority order. Send checks on each candidate pair in priority order. Acknowledge checks received from the other agent

At the end of this handshake, both L and R know that they can send (and receive) messages end-to-end in both directions through the highest priority candidate pair that has passed the connectivity check.

However, the applicant found that: it has been noted that connectivity checks through steps 611 to 615 and steps through 617 to 621 of Fig. 6 will not succeed when both endpoints are behind symmetric NAT. The only combination that would work would be relay to relay combinations in both directions as shown in steps 616 and 622.

Hence the connectivity check for the candidate pairs other than relay-relay, forming the candidate pairs other then relay-relay and calculating the priorities for pairs other then relay-relay shall add significant overhead and performance bottleneck for the calling endpoints. ICE is a generic mechanism to support all NAT pass-through. However the ICE creates a huge call-setup lag when both terminals (end points) are behind symmetric NAT.

SUMMARY

This summary is provided to introduce concepts related to a method thereof for performing a session based on NAT. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.

According to an aspect of the embodiments of the present invention, a method for performing a session based on NAT (Network Address Translator) is provided , the method including:

determining, by a sending endpoint, whether behavior of a local NAT which the sending endpoint is behind and behavior of a remote NAT which a receiving endpoint is behind are a symmetric NAT;

performing, by the sending endpoint with the receiving endpoint, a session over a relay to relay candidate pair, upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT; wherein the relay to relay candidate pair is a relay candidate addresses pair allocated from a Traversal Using Relay NAT (TURN) server to the sending endpoint and the receiving endpoint.

According to another aspect of the embodiments of the present invention, wherein determining, by a sending endpoint, whether behavior of a local NAT which the sending endpoint is behind and behavior of a remote NAT which a receiving endpoint is behind are a symmetric NAT includes:

determining, by the sending endpoint, whether the behavior of the local NAT is a symmetric NAT by querying a TURN server; and

determining, by the sending endpoint, whether the behavior of the remote NAT is a symmetric NAT by querying the TURN server or being informed by the receiving endpoint.

According to another aspect of the embodiments of the present invention, wherein the step of determining, by the sending endpoint, whether the behavior of the local NAT is a symmetric NAT by querying a TURN server includes:

creating and sending, by the sending endpoint, an allocate request message to the TURN server;

receiving, by the sending endpoint, an allocate response message from the TURN server; wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the allocate response message; and

determining, by the sending endpoint, whether the behavior of the local NAT is a symmetric NAT based on the LOCAL-NAT-BEHAVE-RESPONSE attribute carried in the allocate response message.

According to another aspect of the embodiments of the present invention, wherein the step of determining, by the sending endpoint, whether the behavior of the remote NAT is a symmetric NAT by querying the TURN server includes:

creating and sending, by the sending endpoint, a permission request message to the TURN server, wherein a PEER-NAT-BEHAVE-QUERY attribute is carried in the permission request message;

receiving, by the sending endpoint, a permission response message from the TURN server, wherein a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the permission response message; and

determining, by the sending endpoint, whether the behavior of the remote NAT is a symmetric NAT according to the PEER-NAT-BEHAVE -RESPONSE attribute carried in the permission response message.

According to another aspect of the embodiments of the present invention, the method further includes:

sending, by the sending endpoint, information of a host candidate address, a server reflexive candidate address which is a translated transport address on a public side of the NAT and a relay candidate address to the receiving endpoint, wherein the information of a host candidate address, a server reflexive candidate address and a relay candidate address is used for communicating with other receiving endpoints.

According to another aspect of the embodiments of the present invention, the method further includes:

sending, by the sending endpoint, information of a relay candidate address to the receiving endpoint, wherein the information of a relay candidate address is used for communicating with other receiving endpoints.

According to another aspect of the embodiments of the present invention, determining, by the sending endpoint, whether the behavior of the remote NAT is a symmetric NAT being informed by the receiving endpoint includes:

sending, by the sending endpoint, an invite message to the receiving endpoint, wherein the invite message indicates that the behavior of the local NAT is a symmetric NAT;

receiving, by the sending endpoint, a response message which indicates that the behavior of the remote NAT is a symmetric NAT.

According to another aspect of the embodiments of the present invention, wherein the step of performing, by the sending endpoint, a session over the relay to relay candidate pair upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT further includes:

sending, by the sending endpoint, upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT, a Session Description Protocol(SDP) offer message including a first relay candidate address which is allocated from a TURN server to the sending endpoint, to the receving endpoint, wherein a USE-CANDIDATE attribute is carried in the first relay candidate address so as to inform the receving endpoint to return back a second relay candidate address which is allocated from theTURN server to the receving endpoint;

receiving, by the sending endpoint, an SDP answer message including the second relay candidate address from the receving endpoint;

performing, by the sending endpoint, the session with the receving endpoint by using the first relay candidate address and the second relay candidate address, wherein the relay to relay candidate pair includes the first relay candidate address and the second relay candidate address.

According to another aspect of the embodiments of the present invention, a method for performing a session based on NAT is provided, including:

informing, by a receiving endpoint, information which indicates that whether behavior of a remote NAT which the receiving endpoint is behind is a symmetric NAT or not to a sending endpoint or a TURN server;

performing, by the receiving endpoint, a session with the sending endpoint over a relay to relay candidate pair upon determining that behavior of a local NAT which the sending endpoint is behind and the behavior of the remote NAT are a symmetric NAT; wherein the relay to relay candidate pair is a relay candidate addresses pair allocated from a TURN server to the sending endpoint and the receiving endpoint.

According to another aspect of the embodiments of the present invention, the step of informing by a receiving endpoint, information which indicates that whether behavior of remote NAT is a symmetric NAT or not to a sending endpoint further includes:

receiving, by the receiving endpoint, an invite message indicating that the behavior of the local NAT is a symmetric NAT from the sending endpoint;

sending, by the receiving endpoint, a response message indicating that the behavior of the remote NAT is a symmetric NAT to a sending endpoint.

According to another aspect of the embodiments of the present invention, wherein the performing, by the receiving endpoint, a session with the sending endpoint over a relay to relay candidate pair upon determining that behavior of a local NAT which the sending endpoint is behind and the behavior of the remote NAT are a symmetric NAT further includes:

receiving, by the receiving endpoint, from the sending endpoint, a Session Description Protocol(SDP) offer message including a first relay candidate address which is allocated from a TURN server to the sending endpoint, wherein a USE-CANDIDATE attribute is carried in the first relay candidate address so as to inform the receving endpoint to return back a second relay candidate address which is allocated from the TURN server to the receving endpoint;

sending, by the receiving endpoint, an SDP answer message including the second relay candidate address to the sending endpoint;

performing, by the receiving endpoint, the session with the sending endpoint by using the first relay candidate address and the second relay candidate address.

According to another aspect of the embodiments of the present invention, a method for determining behavior of a NAT is provided, including:

receiving, by a TURN server, a request message from a sending endpoint;

sending, by the TURN server, a response message to the sending endpoint, wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the response message, or a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the response message, so that the sending endpoint determines whether behavior of a local NAT which the sending endpoint is behind is a symmetric NAT or determines whether behavior of a remote NAT which a receiving endpoint is behind is a symmetric NAT based on the request message and the response message.

According to another aspect of the embodiments of the present invention, the method further includes:

storing, by the TURN server, the behavior of the local NAT determined by an NAT Behavior Discovery device.

According to another aspect of the embodiments of the present invention, wherein receiving, by a TURN server, a request message from a sending endpoint; and sending, by the TURN server, a response message to the sending endpoint further includes:

receiving, by the TURN server, an allocate request message from the sending endpoint;

sending, by the TURN server, an allocate response message to the sending endpoint, wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the allocate response message, so that the sending endpoint determines the behavior of the local NAT based on the LOCAL-NAT- BEHAVE-RESPONSE attribute carried in the allocate response message from the TURN server.

According to another aspect of the embodiments of the present invention, wherein receiving, by a TURN server, a request message from a sending endpoint; and sending, by the TURN server, a response message to the sending endpoint further includes:

receiving, by the TURN server, a permission request message from the sending endpoint, wherein a PEER-NAT-BEHAVE-QUERY attribute is carried in the permission request message;

sending, by the TURN server, a permission response message to the sending endpoint, wherein a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the permission response message, so that the sending endpoint determines the behavior of the remote NAT according to the PEER-NAT-BEHAVE-RESPONSE attribute carried in the permission response message.

According to another aspect of the embodiments of the present invention, wherein information storied in the NAT behavior discovery device and information storied in the TURN server is refreshed at the trigger of a timer.

According to another aspect of the embodiments of the present invention, a method for determining behavior of a NAT is provided, including:

receiving, by a Session Traversal Utilities for NAT (STUN) server, an STUN binding request message from an NAT Behavior Discovery device;

returning, by the STUN server, an STUN binding response message, to the NAT Behavior Discovery device, wherein a NAT address is carried in the STUN binding response message and a NAT-BEHAVE attribute is included in the NAT address, so that the NAT Behavior Discovery device can determine the behavior of the NAT.

According to another aspect of the embodiments of the present invention, a method for determining behavior of a NAT is provided, including:

sending, by an NAT Behavior Discovery device, an STUN binding request message to an STUN server;

receiving, by the NAT Behavior Discovery device, an STUN binding response message from the STUN server, wherein a NAT address is carried in the STUN binding response message and a NAT-BEHAVE attribute is carried in the NAT address;

determining, by the NAT Behavior Discovery device, behavior of a local NAT which a sending endpoint is behind based on the NAT-BEHAVE attribute included in the NAT address; and

updating, by the NAT Behavior Discovery device, the behavior of the NAT, to the TRUN server.

According to another aspect of the embodiments of the present invention, wherein the method further includes:

determining by using a remote NAT Discovery algorithm, by the NAT Behavior Discovery device, behavior of a remote NAT which a receiving endpoint is behind based on an NAT-BEHAVE attribute included in a server reflexive candidate address of the receiving endpoint, wherein the server reflexive candidate address is a translated transport address on a public side of the NAT; and

updating, by the NAT Behavior Discovery device, the behavior of the remote NAT, to the TRUN server.

According to another aspect of the embodiments of the present invention, a sending endpoint is provided, including:

a memory that stores a plurality of instructions; and

a processor coupled to the memory and configured to execute the instructions to:

determine whether behavior of a local NAT which the sending endpoint is behind and behavior of a remote NAT which a receiving endpoint is behind are a symmetric NAT;

perform a session with the receiving endpoint over a relay to relay candidate pair, upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT; wherein the relay to relay candidate pair is a relay candidate addresses pair allocated from a TURN server to the sending endpoint and the receiving endpoint.

According to another aspect of the embodiments of the present invention, wherein in the step of determining whether behavior of a local NAT which the sending endpoint is behind and behavior of a remote NAT which a receiving endpoint is behind are a symmetric NAT, the processor is further configured to determine whether the behavior of the local NAT is a symmetric NAT by querying a TURN server and determinine whether the behavior of the remote NAT is a symmetric NAT by querying the TURN server or being informed by the receiving endpoint.

According to another aspect of the embodiments of the present invention, wherein in the step of determining whether the behavior of the local NAT is a symmetric NAT by querying a TURN server, the processor is further configured to:

create and send an allocate request message to the TURN server;

receive an allocate response message from the TURN server; wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the allocate response message; and

determine whether the behavior of the local NAT is a symmetric NAT based on the LOCAL-NAT-BEHAVE-RESPONSE attribute carried in the allocate response message.

According to another aspect of the embodiments of the present invention, wherein in the step of determining whether the behavior of the remote NAT is a symmetric NAT by querying the TURN server, the processor is further configured to:

create and send a permission request message to the TURN server, wherein a PEER-NAT-BEHAVE-QUERY attribute is carried in the permission request message;

receive a permission response message from the TURN server, wherein a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the permission response message; and

determine whether the behavior of the remote NAT is a symmetric NAT according to the PEER-NAT-BEHAVE-RESPONSE attribute carried in the permission response message.

According to another aspect of the embodiments of the present invention, wherein the processor is further configured to:

send information of a host candidate address, a server reflexive candidate address which is a translated transport address on a public side of the NAT and a relay candidate address to the receiving endpoint, wherein the information of a host candidate address, a server reflexive candidate address and a relay candidate address is used for communicating with other receiving endpoints.

According to another aspect of the embodiments of the present invention, wherein the processor is further configured to:

send information of a relay candidate address to the receiving endpoint, wherein the information of a relay candidate address is used for communicating with other receiving endpoints.

According to another aspect of the embodiments of the present invention, wherein in the step of determining whether the behavior of the remote NAT is a symmetric NAT being informed by the receiving endpoint, the processor is further configured to:

send an invite message to the receiving endpoint, wherein the invite message indicates that the behavior of the local NAT is a symmetric NAT;

receive a response message which indicates that the behavior of the remote NAT is a symmetric NAT.

According to another aspect of the embodiments of the present invention, wherein in the step of performing a session over the relay to relay candidate pair upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT, the processor further is configured to:

send, upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT, a Session Description Protocol(SDP) offer message including a first relay candidate address which is allocated from a TURN server to the sending endpoint, to the receving endpoint, wherein a USE-CANDIDATE attribute is carried in the first relay candidate address so as to inform the receving endpoint to return back a second relay candidate address which is allocated from the TURN server to the receving endpoint;

receive an SDP answer message including the second relay candidate address from the receving endpoint;

perform the session by using the first relay candidate address and the second relay candidate address, wherein the relay to relay candidate pair includes the first relay candidate address and the second relay candidate address.

According to another aspect of the embodiments of the present invention, a receiving endpoint is provided, including:

a memory that stores a plurality of instructions; and

a processor coupled to the memory and configured to execute the instructions to:

inform information which indicates that whether behavior of a remote NAT which the receiving endpoint is behind is a symmetric NAT or not to a sending endpoint or a TURN server;

perform a session over a relay to relay candidate pair with the sending endpoint upon determining that behavior of a local NAT which the sending endpoint is behind and the behavior of the remote NAT are a symmetric NAT ; wherein the relay to relay candidate pair is a relay candidate addresses pair allocated from a TURN server to the sending endpoint and the receiving endpoint.

According to another aspect of the embodiments of the present invention, wherein in the step of informing information which indicates that whether behavior of remote NAT is a symmetric NAT or not to a sending endpoint, the processor further is configured to receive an invite message indicating that the behavior of the local NAT is a symmetric NAT from the sending endpoint;

send the response message indicating that the behavior of the remote NAT is a symmetric NAT to a sending endpoint.

According to another aspect of the embodiments of the present invention, wherein in the step of performing a session over the relay to relay candidate pair upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT, the processor is further configured to:

receive a Session Description Protocol(SDP) offer message including a first relay candidate address which is allocated from a TURN server to the sending endpoint, wherein a USE-CANDIDATE attribute is carried in the first relay candidate address so as to inform the receving endpoint to return back a second relay candidate address which is allocated from the TURN server to the receving endpoint;

send an SDP answer message including the second relay candidate address to the sending endpoint;

perform the session with the sending endpoint by using the first relay candidate address and the second relay candidate address.

According to another aspect of the embodiments of the present invention, a TURN server is provided, including:

a memory that stores a plurality of instructions; and

a processor coupled to the memory and configured to execute the instructions to:

receive a request message from a sending endpoint;

send a response message to the sending endpoint, wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the response message, or a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the response message, so that the sending endpointdetermines whether behavior of a local NAT which the sending endpoint is behind is a symmetric NAT or determines whether behavior of a remote NAT which a receiving endpoint is behind is a symmetric NAT based on the request message and the response message.

According to another aspect of the embodiments of the present invention, wherein the processor is further configured to store the behavior of the local NAT determined by an NAT Behavior Discovery device.

According to another aspect of the embodiments of the present invention, wherein in the step of receiving a request message from a sending endpoint and sending a response message to the sending endpoint, the processor is further configured to:

receive an allocate request message from the sending endpoint;

send an allocate response message to the sending endpoint, wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the allocate response message, so that the sending endpoint determines the behavior of the local NAT based on the LOCAL-NAT-BEHAVE-RESPONSE attribute carried in the allocate response message from the TURN server.

According to another aspect of the embodiments of the present invention, wherein in the step of receiving a request message from a sending endpoint and sending a response message to the sending endpoint, the processor is further configured to:

receive a permission request message from the sending endpoint, wherein a PEER-NAT-BEHAVE-QUERY attribute is carried in the permission request message;

send a permission response message to the sending endpoint, wherein a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the permission response message,

so that the sending endpoint determines the behavior of the remote NAT according to the PEER-NAT-BEHAVE-RESPONSE attribute carried in the permission response message.

According to another aspect of the embodiments of the present invention, an STUN is provided, including:

a memory that stores a plurality of instructions; and

a processor coupled to the memory and configured to execute the instructions to:

receive an STUN binding request message from an NAT Behavior Discovery device;

return an STUN binding response message, to the NAT Behavior Discovery device, wherein a NAT address is carried in the STUN binding response message and a NAT-BEHAVE attribute is included in the NAT address,, so that the NAT Behavior Discovery device can determine the behavior of the NAT.

According to another aspect of the embodiments of the present invention, an NAT Behavior Discovery device is provided, including:

a memory that stores a plurality of instructions; and

a processor coupled to the memory and configured to execute the instructions to:

send an STUN binding request message to an STUN server;

receive an STUN binding response message from the STUN server, wherein a NAT address is carried in the STUN binding response message and a NAT-BEHAVE attribute is carried in the NAT address;

determine behavior of a local NAT which a sending endpoint is behind based on the NAT-BEHAVE attribute included in the NAT address; and

update the behavior of the local NAT, to the TRUN server.

According to another aspect of the embodiments of the present invention, wherein the processor is further configured to employ a remote NAT Discovery algorithm to determine behavior of a remote NAT which a receiving endpoint is behind based on an NAT-BEHAVE attribute included in a server reflexive candidate address of the receiving endpoint, wherein the server reflexive candidate address is a translated transport address on a public side of the NAT; and

update the behavior of the remote NAT, to the TRUN server.

The advantages of embodiments of the present invention exist in that: upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT, a session over a relay to relay candidate pair is performed, thereby eliminating the unnecessary portions of ICE procedures when both endpoints are behind symmetric NAT, resulting in a higher connection establishment speed.

These and further aspects and features of the present invention will be apparent with reference to the following description and attached drawings. In the description and drawings, particular embodiments of the invention have been disclosed in detail as being indicative of some of the ways in which the principles of the invention may be employed, but it is understood that the invention is not limited correspondingly in scope. Rather, the invention includes all changes, modifications and equivalents coming within the spirit and terms of the appended claims.

Features that are described and/or illustrated with respect to one embodiment may be used in the same way or in a similar way in one or more other embodiments and/or in combination with or instead of the features of the other embodiments.

It should be emphasized that the term “comprises/comprising” when used in this specification is taken to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

Many aspects of the invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. To facilitate illustrating and describing some parts of the invention, corresponding portions of the drawings may be exaggerated in size, e.g., made larger in relation to other parts than in an exemplary device actually made according to the invention. Elements and features depicted in one drawing or embodiment of the invention may be combined with elements and features depicted in one or more additional drawings or embodiments. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views and may be used to designate like or similar parts in more than one embodiment.

BRIEF DESCRIPTION OF THE DRAWING

The drawings are included to provide further understanding of the present invention, which constitute a part of the specification and illustrate the embodiments of the present invention, and are used for setting forth the principles of the present invention together with the description. The same element is represented with the same reference number throughout the drawings.

In the drawings:

Figure 1-4 are schematic diagrams of four different forms of NAT in the prior art;

Figure 5 is a schematic diagram of ICE deployment environment in the piror art;

Figure 6 is a flowchart of a method for session establishment based on NAT in the prior art;

Figure 7 is a schematic diagram of the relationship between a relay candidate, a server reflexive candidate and a host candidate;

Figure 8 is a flowchart of a method for session establishment based on NAT provided according to embodiment 1 of the present invention;

Figure 9 is a flowchart of the step 801 in accordance with embodiment 1 of the present invention;

Figure 10 is a schematic diagram of LOCAL-NAT-BEHAVE- RESPONSE attribute in accordance with embodiment 1 of the present invention;

Figure 11 is a flowchart of the step 801 in accordance with embodiment 1 of the present invention;

Figure 12A and 12B are schematic diagrams of the above implementation of embodiment 1 of the present invention;

Figure 13 is a flowchart of the step 801 in accordance with embodiment 1 of the present invention;

Figure 14 is a specific schematic diagram of the above implementation of embodiment 2 of the present invention;

Figure 15 is a flowchart of the method for performing a session based on NAT in accordance with embodiment 3 of the present invention;

Figure 16 is a flowchart of the step 1501 in accordance with embodiment 3 of the present invention;

Figure 17 is a flowchart of the method for determining behavior of NAT in accordance with embodiment 4 of the present invention;

Figure 18 is a flowchart of the method for determining behavior of NAT in accordance with embodiment 5 of the present invention;

Figure 19 is a flowchart of the method for determining behavior of NAT in accordance with embodiment 6 of the present invention;

Figure 20 is a schematic diagram of the above implementation of embodiment 6 of the present invention;

Figure 21 is a schematic diagram of the client in accordance with an embodiment 7 of the present invention;

Figure 22 is a schematic diagram of the client in accordance with an embodiment 8 of the present invention;

Figure 23 is a schematic diagram of the TURN server in accordance with an embodiment 9 of the present invention;

Figure 24 is a schematic diagram of the STUN server in accordance with an embodiment 10 of the present invention;

Figure 25 is a schematic diagram of the device in accordance with an embodiment 11 of the present invention;

Figure 26 is a schematic structure diagram of the client according to an embodiment 12 of the present invention;

Figure 27 is a schematic structure diagram of the client according to an embodiment 13 of the present invention;

Figure 28 is a schematic structure diagram of the client according to an embodiment 14 of the present invention;

Figure 29 is a schematic structure diagram of the client according to an embodiment 15 of the present invention;

Figure 30 is a schematic structure diagram of the client according to an embodiment 16 of the present invention;

Figure 31 is a schematic diagram of the system in accordance with an embodiment 17 of the present invention.

DETAILED DESCRIPTION

The many features and advantages of the embodiments are apparent from the detailed specification and, thus, it is intended by the appended claims to cover all such features and advantages of the embodiments that fall within the true spirit and scope thereof. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the inventive embodiments to the exact construction and operation illustrated and described, and accordingly all suitable modifications and equivalents may be resorted to, falling within the scope thereof.

The embodiments of the present invention are described as follows in reference to the drawings.

The embodiments of the present invention can be applied to any end to end data transmission application that wishes to make use of ICE service. Such an application may include SIP, XMPP/Jingle etc.

Embodiment 1

This embodiment of the present invention provides a method for performing a session based on NAT.

Figure 8 is a flowchart of the method for performing a session based on NAT in accordance with embodiment 1 of the present invention. As shown in Fig.8, for a sending endpoint side, the method includes:

Step 801, determining, by a sending endpoint, whether behavior of a local NAT which the sending endpoint is behind and behavior of a remote NAT which a receiving endpoint is behind are a symmetric NAT;

Step 802, performing, by the sending endpoint with the receiving endpoint, a session over a relay to relay candidate pair, upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT; wherein the relay to relay candidate pair is a relay candidate addresses pair allocated from a Traversal Using Relay NAT (TURN) server to the sending endpoint and the receiving endpoint.

In one implementation of step 801 in embodiment 1 of the present invention, the sending endpoint determines whether behavior of a local NAT which the sending endpoint is behind is a symmetric NAT by querying a TURN server.

Figure 9 is a flowchart of the step 801 in accordance with embodiment 1 of the present invention. As shown in Fig.9, the method includes:

Step 901, creating and sending, by the sending endpoint, an allocate request message to the TURN server;

Step 902, receiving, by the sending endpoint, an allocate response message from the TURN server; wherein a LOCAL-NAT-BEHAVE- RESPONSE attribute is carried in the allocate response message; and

Step 903, determining, by the sending endpoint, whether the behavior of the local NAT is a symmetric NAT based on the LOCAL-NAT-BEHAVE- RESPONSE attribute carried in the allocate response message.

Figure 10 is a schematic diagram of LOCAL-NAT-BEHAVE- RESPONSE attribute in accordance with embodiment 1 of the present invention. As shown in Fig 10, the value of the Family field is set to 0x01 for IPv4 as per RFC 5389. The Address field carries the NAT IP address (SA) that should be added to the TURN server.

In one implementation of step 801 in embodiment 1 of the present invention, the sending endpoint determines whether behavior of a remote NAT which a receiving endpoint is behind is a symmetric NAT by querying a TURN server.

Figure 11 is a flowchart of the step 801 in accordance with embodiment 1 of the present invention. As shown in Fig.11, the method includes:

Step 1101, creating and sending, by the sending endpoint, a permission request message to the TURN server, wherein a PEER-NAT-BEHAVE- QUERY attribute is carried in the permission request message;

Step 1102, receiving, by the sending endpoint, a permission response message from the TURN server, wherein a PEER-NAT-BEHAVE- RESPONSE attribute is carried in the permission response message;

Step 1103, determining, by the sending endpoint, whether the behavior of the remote NAT is a symmetric NAT according to the PEER-NAT- BEHAVE-RESPONSE attribute carried in the permission response message.

Wherein the PEER-NAT-BEHAVE-QUERY and PEER-NAT-BEHAVE- RESPONSE attributes are also shown in Fig. 10, and herein is omitted.

In step 802, wherein the step of performing, by the sending endpoint, a session over the relay to relay candidate pair upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT further includes:sending, by the sending endpoint, upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT, a Session Description Protocol(SDP) offer message including a first relay candidate address which is allocated from a TURN server to the sending endpoint, to the receving endpoint, wherein a USE-CANDIDATE attribute is carried in the first relay candidate address so as to inform the receving endpoint to return back a second relay candidate address which is allocated from theTURN server to the receving endpoint; receiving, by the sending endpoint, an SDP answer message including the second relay candidate address from the receving endpoint; performing, by the sending endpoint, the session with the receving endpoint by using the first relay candidate address and the second relay candidate address, wherein the relay to relay candidate pair includes the first relay candidate address and the second relay candidate address.

Wherein the method of the embodiment 1 of the present invention further includes: sending, by the sending endpoint, information of a host candidate address, a server reflexive candidate address which is a translated transport address on a public side of the NAT and a relay candidate address to the receiving endpoint, wherein the information of a host candidate address, a server reflexive candidate address and a relay candidate address is used for communicating with other receiving endpoints.

Figure 12A and 12B are specific schematic diagrams of the above implementation of embodiment 1 of the present invention. As shown in Fig.12:

when there is a new call from endpoint A to endpoint B which can be any endpoints in the network behind two NATs, endpoint A initiates ICE procedure by gathering candidates; wherein, when there is a new call from endpoint A to endpoint B (which can be any endpoints in the network behind the two NATs), endpoint A initiates ICE procedure by gathering candidates, one of which is the relay candidate.

The Create allocate response message carries the LOCAL-NAT- BEHAVE-RESPONSE attribute which indicates that the endpoint A in behind a symmetric NAT. The format of this attribute is as shown in Fig. 10, and herein is omitted.

Endpoint A exchanges its candidates and receives similar candidates from endpoint B. the endpoint A creates permission for the received candidates from endpoint B with the CreatePermission request to the TURN server. Wherein, it also adds a new attribute PEER-NAT-BEHAVE-QUERY carrying the server reflexive candidate address (SB) exchanged by endpoint B.

The CreatePermission response message carries the PEER-NAT- BEHAVE-RESPONSE attribute, the presence of which indicates that the address carried in the PEER-NAT-BEHAVE-QUERY represents a symmetric NAT. The endpoint A, upon determining that both nodes are behind symmetric NAT, directly sends a USE-CANDIDATE attribute over the relay to relay candidate pair and can start sending the media directly.

It can be seen from the above embodiment that: upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT then performing a session over a relay to relay candidate pair, thereby eliminating the unnecessary portions of ICE procedures when both endpoints are behind symmetric NAT, resulting in a higher connection establishment speed.

Wherein the method of the embodiment 1 of the present invention further includes: sending, by the sending endpoint, information of a relay candidate address to the receiving endpoint, wherein the information of a relay candidate address is used for communicating with other receiving endpoints.

As shown in Fig. 12A and 12B also, consider a case where endpoint B calls endpoint A by gathering its candidates (HB, SB, RB) and exchanges it with endpoint A through a rendezvous protocol. Endpoint A will initiate ICE procedures by gathering candidates, one of which is the relay candidate at the TURN server. The CreateAllocate request message to the TURN server will also carry the server reflexive candidate address of endpoint B (SB) in the PEER-NAT-BEHAVE-QUERY attribute, indicating the TURN server that it is interested to know the behavior of the NAT covering Endpoint B. In the CreateAllocate response message indicating the allocated relay candidate, the TURN server also includes two attributes called the LOCAL-NAT-BEHAVE- RESPONSE and PEER-NAT-BEHAVE-RESPONSE. The presence of LOCAL-NAT-BEHAVE-RESPONSE attribute indicates that endpoint A is behind symmetric NAT and the presence of PEER-NAT-BEHAVE- RESPONSE indicates that endpoint B is behind a symmetric NAT. All new attributes defined in this embodiment adopts the structure shown in Fig. 10.

Now since endpoint A is yet to advertise its candidates, Endpoint A will only advertise the relay candidate (RA), since the only combination that would work is relay-relay (RA-RB) when both endpoints are behind symmetric NAT. This would also result in reduced candidate pair formation at endpoint B. Endpoint A will then send a USE-CANDIDATE attribute directly on the relay-relay (RA-RB) candidate pair.

In this embodiment, information storied in the NAT behavior discovery device and information storied in the TURN server is refreshed at the trigger of a timer.

It can be seen from the above embodiment that: by send information of a relay candidate address to the receiving endpoint only, thereby avoiding performing formation of any candidate pairs other than relay-relay, avoiding calculating their priority, and avoiding performing the connectivity checks.

Embodiment 2

This embodiment of the present invention provides a method for performing a session based on NAT, the same content will not be described. The difference between embodiment 2 and embodiment 1 is that the sending endpoint determines whether the receiving endpoint is a behind symmetric NAT by being informed by the receiving endpoint.

According to the above difference, Figure 13 is a flowchart of the step 801 in accordance with embodiment 1 of the present invention. As shown in Fig.13, for the sending endpoint side, the method includes:

Step 1301, sending, by the sending endpoint, an invite message to the receiving endpoint, wherein the invite message indicates that the behavior of the local NAT is a symmetric NAT;

Step 1302, receiving, by the sending endpoint, a response message which indicates that the behavior of the remote NAT is a symmetric NAT.

Figure 14 is a specific schematic diagram of the above implementation of embodiment 2 of the present invention. As shown in Fig.14:

This information about the NAT behavior can also be passed explicitly to the remote peer over a rendezvous protocol (Ex SIP, Jingle etc.) as shown in Fig.14. Whenever the Host A (HA) wants to initiate a call, it initiates the NAT Behavior Discovery procedures which can refer to embodiment 1 and herein is omitted. If the NAT type is known to be symmetric NAT, then the client may add a symmetric NAT attribute in the INVITE message which is sent to its peer (Host B). The presence of this attribute in the SIP INVITE message indicates to the peer (B) that the caller (A) is behind a Symmetric NAT.

When the INVITE is received at B, since the caller (A) is behind symmetric NAT, Host B would also initiate the NAT Behavior Discovery procedures which can refer to embodiment 1 and herein is omitted. If this NAT also turns out to be symmetric then, the Symmetric NAT attribute is added in the 200 OK response from Host B to Host A.

When this message gets delivered to Host A, it realizes that both Host A and Host B are behind symmetric NAT’s. Since the data in this embodiment can travel only through the relay, the relay to relay candidates are chosen for data transfer.

In this embodiment, information storied in the NAT behavior discovery device and information storied in the TURN server is refreshed at the trigger of a timer.

It can be seen from the above embodiment that: upon determining that both a sending endpoint and a receiving endpoint are behind symmetric NAT then performing a session over a relay to relay candidate pair, thereby eliminating the unnecessary portions of ICE procedures when both endpoints are behind symmetric NAT, resulting in a higher connection establishment speed.

Embodiment 3

This embodiment of the present invention provides a method for performing a session based on NAT.

Figure 15 is a flowchart of the method for performing a session based on NAT in accordance with embodiment 3 of the present invention. As shown in Fig.15, for the receiving endpoint side, the method includes:

step 1501, informing, by a receiving endpoint, information which indicates that whether behavior of a remote NAT which the receiving endpoint is behind is a symmetric NAT or not to a sending endpoint or a TURN server;

step 1502, performing, by the receiving endpoint, a session with the sending endpoint over a relay to relay candidate pair upon determining that behavior of a local NAT which the sending endpoint is behind and the behavior of the remote NAT are a symmetric NAT; wherein the relay to relay candidate pair is a relay candidate addresses pair allocated from a TURN server to the sending endpoint and the receiving endpoint.

Figure 16 is a flowchart of the step 1501 in accordance with embodiment 3 of the present invention. As shown in Fig.15, the method includes:

step 1601, receiving, by the receiving endpoint, an invite message indicating that the behavior of the local NAT is a symmetric NAT from the sending endpoint;

step 1602, sending, by the receiving endpoint, a response message indicating that the behavior of the remote NAT is a symmetric NAT to a sending endpoint.

In step 1502, after determining that behavior of a local NAT which the sending endpoint is behind and the behavior of the remote NAT are a symmetric NAT, the method further includes: receiving, by the receiving endpoint, from the sending endpoint, a Session Description Protocol(SDP) offer message including a first relay candidate address which is allocated from a TURN server to the sending endpoint, wherein a USE-CANDIDATE attribute is carried in the first relay candidate address so as to inform the receving endpoint to return back a second relay candidate address which is allocated from the TURN server to the receving endpoint; sending, by the receiving endpoint, an SDP answer message including the second relay candidate address to the sending endpoint; performing, by the receiving endpoint, the session with the sending endpoint by using the first relay candidate address and the second relay candidate address.

In this embodiment, information storied in the NAT behavior discovery device and information storied in the TURN server is refreshed at the trigger of a timer.

It can be seen from the above embodiment that: upon determining that behavior of a local NAT which the sending endpoint is behind and the behavior of the remote NAT are a symmetric NAT then performing a session over a relay to relay candidate pair, thereby eliminating the unnecessary portions of ICE procedures when both endpoints are behind symmetric NAT, resulting in a higher connection establishment speed.

Embodiment 4

This embodiment of the present invention provides a method for determining behavior of a NAT.

Figure 17 is a flowchart of the method for determining behavior of a NAT in accordance with embodiment 4 of the present invention. As shown in Fig.17, for a TURN server side, the method includes:

step 1701, receiving, by a TURN server, a request message from a sending endpoint;

step 1702, sending, by the TURN server, a response message to the sending endpoint, wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the response message, or a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the response message, so that the sending endpoint determines whether behavior of a local NAT which the sending endpoint is behind is a symmetric NAT or determines whether behavior of a remote NAT which a receiving endpoint is behind is a symmetric NAT based on the request message and the response message.

In this embodiment of the present invention, the method further includes:

step 1703, storing, by the TURN server, the behavior of the local NAT determined by an NAT Behavior Discovery device.

In one implementation of this embodiment, the request message can be an allocate request message, and the response message can be an allocate response message. Wherein the sending endpoint determines the behavior of the local NAT further including:receiving, by the TURN server, an allocate request message from the sending endpoint; sending, by the TURN server, an allocate response message to the sending endpoint, wherein a LOCAL-NAT- BEHAVE-RESPONSE attribute is carried in the allocate response message, so that the sending endpoint determines the behavior of the local NAT based on the LOCAL-NAT-BEHAVE-RESPONSE attribute carried in the allocate response message from the TURN server.

In another implementation of this embodiment, the request message can be a permission request message, and the response message can be a permission response message. Wherein the sending endpoint determines the behavior of the remote NAT further including: receiving, by the TURN server, a permission request message from the sending endpoint, wherein a PEER-NAT-BEHAVE-QUERY attribute is carried in the permission request message; sending, by the TURN server, a permission response message to the sending endpoint, wherein a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the permission response message, so that the sending endpoint determines the behavior of the remote NAT according to the PEER-NAT-BEHAVE-RESPONSE attribute carried in the permission response message.

In this embodiment, information storied in the NAT behavior discovery device and information storied in the TURN server is refreshed at the trigger of a timer.

Embodiment 5

This embodiment of the present invention provides a method for determining behavior of a NAT

Figure 18 is a flowchart of the method for determining behavior of a NAT in accordance with embodiment 5 of the present invention. As shown in Fig.18, for the STUN server side, the method includes:

step 1801, receiving, by a Session Traversal Utilities for NAT (STUN) server, an STUN binding request message from an NAT Behavior Discovery device;

step 1802, returning, by the STUN server, an STUN binding response message, to the NAT Behavior Discovery device, wherein a NAT address is carried in the STUN binding response message and a NAT-BEHAVE attribute is included in the NAT address, so that the NAT Behavior Discovery device can determine the behavior of the NAT.

Embodiment 6

This embodiment of the present invention provides a method for determining behavior of a NAT

Figure 19 is a flowchart of the method for determining behavior of a NAT in accordance with embodiment 6 of the present invention. As shown in Fig.19, the method includes:

step 1901, sending, by an NAT Behavior Discovery device, an STUN binding request message to an STUN server;

step 1902, receiving, by the NAT Behavior Discovery device, an STUN binding response message from the STUN server, wherein a NAT address is carried in the STUN binding response message and a NAT-BEHAVE attribute is carried in the NAT address;

step 1903, determining, by the NAT Behavior Discovery device, behavior of a local NAT which a sending endpoint is behind based on the NAT-BEHAVE attribute included in the NAT address;

step 1904, updating, by the NAT Behavior Discovery device, the behavior of the NAT, to the TRUN server.

Figure 20 is a specific schematic diagram of the above implementation of embodiment 6 of the present invention. As shown in Fig.20:

A managed endpoint in the network called the NBD (NAT Behavior Discovery) device performs the behavior discovery of NAT (1), finds that it is behind a symmetric NAT and updates this information in the TURN server (2). The parameter used to identify the network, is the NAT address returned by the STUN server in the STUN binding response message (SA). This information is made publicly available for all the callers within the network. The NBD defines a new attribute to the STUN protocol called NAT-BEHAVE attribute that is used to add the NAT address in the TURN server.

In this embodiment of the present invention, wherein the method further comprises:

step 1905, determining by using a remote NAT Discovery algorithm, by the NAT Behavior Discovery device, behavior of a remote NAT which a receiving endpoint is behind based on an NAT-BEHAVE attribute included in a server reflexive candidate address of the receiving endpoint, wherein the server reflexive candidate address is a translated transport address on a public side of the NAT; and

step 1906, updating, by the NAT Behavior Discovery device, the behavior of the remote NAT, to the TRUN server.

Embodiment 7

This embodiment of the present invention further provides a client. This embodiment corresponds to the method of the above embodiment 1 or 2, and the same content will not be described.

Figure 21 is a schematic diagram of the client in accordance with an embodiment of the present invention. As shown in Figure 21, the client 2100 includes: a determining unit 2101, a first performing unit 2102. Other parts of the client can refer to the existing technology and not be described in the present application. However, it is not limited thereto, and particular implement way may be determined as actually required, wherein,

a determining unit 2101, configure to determine whether behavior of a local NAT which the sending endpoint is behind and behavior of a remote NAT which a receiving endpoint is behind are a symmetric NAT;

a first performing unit 2102, configure to perform a session with the receiving endpoint over a relay to relay candidate pair, upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT; wherein the relay to relay candidate pair is a relay candidate addresses pair allocated from a TURN server to the sending endpoint and the receiving endpoint.

In one implementation of this embodiment, wherein the determining unit 2101 is further configured to determine whether the behavior of the local NAT is a symmetric NAT by querying a TURN server, the determining unit 2101 further includes:

a first creating unit 21111, configure to create and send an allocate request message to the TURN server;

a first receiving unit 21112, configure to receive an allocate response message from the TURN server; wherein a LOCAL-NAT-BEHAVE- RESPONSE attribute is carried in the allocate response message

the determining unit 2101 further configured to whether the behavior of the local NAT is a symmetric NAT based on the LOCAL-NAT-BEHAVE- RESPONSE attribute carried in the allocate response message.

In one implementation of this embodiment, the determining unit 2101 further is configured to determine whether the behavior of the remote NAT is a symmetric NAT by querying the TURN server, the determining unit 2101 further includes:

a second creating unit 21113, configure to create and send a permission request message to the TURN server, wherein a PEER-NAT-BEHAVE- QUERY attribute is carried in the permission request message;

a second receiving unit 21114, configure to receive a permission response message from the TURN server, wherein a PEER-NAT-BEHAVE- RESPONSE attribute is carried in the permission response message;

the determining unit 2101 further configured to determine whether the behavior of the remote NAT is a symmetric NAT according to the PEER-NAT-BEHAVE-RESPONSE attribute carried in the permission response message.

In this implementation, wherein, the client further includes:

a first sending unit 2103, configured to s send information of a host candidate address, a server reflexive candidate address which is a translated transport address on a public side of the NAT and a relay candidate address to the receiving endpoint, wherein the information of a host candidate address, a server reflexive candidate address and a relay candidate address is used for communicating with other receiving endpoints. Or,

a second sending unit 2104, configured to send information of a relay candidate address to the receiving endpoint, wherein the information of a relay candidate address is used for communicating with other receiving endpoints.

In another implementation of this embodiment, the determining unit 2101 is further configured to determine whether the behavior of the remote NAT is a symmetric NAT being informed by the receiving client. Wherein the determining unit 2101 further includes:

a third sending unit 21115, configured to send an invite message to the receiving endpoint, wherein the invite message indicates that the behavior of the local NAT is a symmetric NAT;

a third receiving unit 21116, configure to receive a response message which indicates that the behavior of the remote NAT is a symmetric NAT.

In this embodiment, the first performing unit 2102 further includes:

a fourth sending unit 21021, configured to send, upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT, a Session Description Protocol(SDP) offer message including a first relay candidate address which is allocated from a TURN server to the sending endpoint, to the receiving endpoint, wherein a USE-CANDIDATE attribute is carried in the first relay candidate address so as to inform the receiving endpoint to return back a second relay candidate address which is allocated from the TURN server to the receiving endpoint;

a fourth receiving unit 21022, receive an SDP answer message including the second relay candidate address from the receiving endpoint;

a first performing unit 2102 is further configured to perform the session by using the first relay candidate address and the second relay candidate address, wherein the relay to relay candidate pair includes the first relay candidate address and the second relay candidate address.

It can be seen from the above embodiment that: upon determining that both a sending endpoint and a receiving endpoint are behind symmetric NAT then performing a session over a relay to relay candidate pair, thereby eliminating the unnecessary portions of ICE procedures when both endpoints are behind symmetric NAT, resulting in a higher connection establishment speed.

Embodiment 8

This embodiment of the present invention further provides a client. This embodiment corresponds to the method of the above embodiment 3, and the same content will not be described.

Figure 22 is a schematic diagram of the client in accordance with an embodiment of the present invention. As shown in Figure 22, the client 2200 includes: an informing unit 2201, a second performing unit 2202. Other parts of the client can refer to the existing technology and not be described in the present application. However, it is not limited thereto, and particular implement way may be determined as actually required, wherein,

an informing unit 2201, configured to inform information which indicates that whether behavior of a remote NAT which the receiving endpoint is behind is a symmetric NAT or not to a sending endpoint or a TURN server;

a second performing unit 2202, configure to perform a session over a relay to relay candidate pair with the sending endpoint upon determining that behavior of a local NAT which the sending endpoint is behind and the behavior of the remote NAT are a symmetric NAT; wherein the relay to relay candidate pair is a relay candidate addresses pair allocated from a TURN server to the sending endpoint and the receiving endpoint.

In one implementation of this embodiment, wherein the informing unit 2201 further includes:

a fifth receiving unit 22011, configured to receiveb an invite message indicating that the behavior of the local NAT is a symmetric NAT from the sending endpoint;

a fifth sending unit 22012, configured to send the response message indicating that the behavior of the remote NAT is a symmetric NAT to a sending endpoint.

In this embodiment, wherein the second performing unit 2202 further includes:

a sixth receiving unit 22021, configured to receive a Session Description Protocol (SDP) offer message including a first relay candidate address which is allocated from a TURN server to the sending endpoint, wherein a USE-CANDIDATE attribute is carried in the first relay candidate address so as to inform the receiving endpoint to return back a second relay candidate address which is allocated from the TURN server to the receiving endpoint;

a sixth sending unit 22022, configured to send an SDP answer message including the second relay candidate address to the sending endpoint;

a second performing unit 2202 is further configure to perform the session with the sending endpoint by using the first relay candidate address and the second relay candidate address.

It can be seen from the above embodiment that: upon determining that both a sending endpoint and a receiving endpoint are behind symmetric NAT then performing a session over a relay to relay candidate pair, thereby eliminating the unnecessary portions of ICE procedures when both endpoints are behind symmetric NAT, resulting in a higher connection establishment speed.

Embodiment 9

This embodiment of the present invention further provides a TURN server. This embodiment corresponds to the method of the above embodiment 4, and the same content will not be described.

Figure 23 is a schematic diagram of the TURN server in accordance with an embodiment of the present invention. As shown in Figure 23, the TURN server 2300 includes: a seventh receiving unit 2301, a seventh sending unit 2302. Other parts of the TURN server can refer to the existing technology and not be described in the present application. However, it is not limited thereto, and particular implement way may be determined as actually required, wherein,

a seventh receiving unit 2301, configured to receive a request message from a sending endpoint;

a seventh sending unit 2302, configured to send a response message to the sending endpoint, wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the response message, or a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the response message, so that the sending endpoint determines whether behavior of a local NAT which the sending endpoint is behind is a symmetric NAT or determines whether behavior of a remote NAT which a receiving endpoint is behind is a symmetric NAT based on the request message and the response message.

In this embodiment, wherein the TURN server further includes:

a storing unit 2303, configured to store the behavior of the local NAT determined by an NAT Behavior Discovery device.

In one implementation of this embodiment, wherein a seventh receiving unit 2301 is further configured to receive an allocate request message from the sending endpoint; and send an allocate response message to the sending endpoint, wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the allocate response message, so that the sending endpoint determines the behavior of the local NAT based on the LOCAL-NAT-BEHAVE-RESPONSE attribute carried in the allocate response message from the TURN server.

In another implementation of this embodiment, wherein a seventh receiving unit 2301 is further configured to receive a permission request message from the sending endpoint, wherein a PEER-NAT-BEHAVE-QUERY attribute is carried in the permission request message; and send a permission response message to the sending endpoint, wherein a PEER-NAT-BEHAVE- RESPONSE attribute is carried in the permission response message, so that the sending endpoint determines the behavior of the remote NAT according to the PEER-NAT-BEHAVE-RESPONSE attribute carried in the permission response message.

In this embodiment, information storied in the NAT behavior discovery device and information storied in the TURN server is refreshed at the trigger of a timer.

Embodiment 10

This embodiment of the present invention further provides a STUN server. This embodiment corresponds to the method of the above embodiment 5, and the same content will not be described.

Figure 24 is a schematic diagram of the STUN server in accordance with an embodiment of the present invention. As shown in Figure 24, the STUN server 2400 includes: an eighth receiving unit 2401, a returning unit 2402. Other parts of the STUN server can refer to the existing technology and not be described in the present application. However, it is not limited thereto, and particular implement way may be determined as actually required, wherein,

an eighth receiving unit 2401, configured to receive an STUN binding request message from an NAT Behavior Discovery device;

a returning unit 2402, configured to return an STUN binding response message, to the NAT Behavior Discovery device, wherein a NAT address is carried in the STUN binding response message and a NAT-BEHAVE attribute is included in the NAT address, so that the NAT Behavior Discovery device can determine the behavior of the NAT.

Embodiment 11

This embodiment of the present invention further provides a device which is configured in a client. This embodiment corresponds to the method of the above embodiment 6, and the same content will not be described.

Figure 25 is a schematic diagram of the device in accordance with an embodiment of the present invention. As shown in Figure 25, the device 2500 includes: an eighth sending unit 2501, a ninth receiving unit 2502, a determining unit 2503, and an updating unit 2504. Other parts of the device can refer to the existing technology and not be described in the present application. However, it is not limited thereto, and particular implement way may be determined as actually required, wherein,

an eighth sending unit 2501, configured to send an STUN binding request message to an STUN server;

a ninth receiving unit 2502, configured to receive an STUN binding response message from the STUN server, wherein a NAT address is carried in the STUN binding response message and a NAT-BEHAVE attribute is carried in the NAT address;

a determining unit 2503, configured to determine behavior of a local NAT which a sending endpoint is behind based on the NAT-BEHAVE attribute included in the NAT address;

an updating unit 2504, configured to update the behavior of the local NAT, to the TRUN server.

In one implementation of this embodiment, a determining unit 2503 is further configured to employ a remote NAT Discovery algorithm to determine behavior of a remote NAT which a receiving endpoint is behind based on an NAT-BEHAVE attribute included in a server reflexive candidate address of the receiving endpoint, wherein the server reflexive candidate address is a translated transport address on a public side of the NAT; and

an updating unit 2504 is further configured to update the behavior of the remote NAT, to the TRUN server.

The present invention also provides a non-transitory computer readable storage medium, including computer program codes which when executed by a computer processor causes the compute processor to execute the method for session establishment based on NAT according to embodiments of the present invention.

Embodiment 12

This embodiment of the present invention further provides a sending endpoint. This embodiment corresponds to the method of the above embodiment 1-2, and the same content will not be described.

In this embodiment, the sending endpoint includes a processor and a memory coupled to the processor.

FIG. 26 is a schematic structure diagram of the sending endpoint according to an embodiment of the present invention. As shown in FIG. 26, there is a memory 42 that stores a plurality of instructions; and a processor 41 coupled to the memory 42The memory 42, configured to store program. Specifically, the program can includes program code, the program code includes computer operating instruction.

the processor 41 is configured to execute the instructions to:

determine whether behavior of a local NAT which the sending endpoint is behind and behavior of a remote NAT which a receiving endpoint is behind are a symmetric NAT;

perform a session with the receiving endpoint over a relay to relay candidate pair, upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT; wherein the relay to relay candidate pair is a relay candidate addresses pair allocated from a TURN server to the sending endpoint and the receiving endpoint.

In one implementation of this embodiment, wherein in the step of determining whether behavior of a local NAT which the sending endpoint is behind and behavior of a remote NAT which a receiving endpoint is behind are a symmetric NAT, the processor 41 is further configured to determine whether the behavior of the local NAT is a symmetric NAT by querying a TURN server and determine whether the behavior of the remote NAT is a symmetric NAT by querying the TURN server or being informed by the receiving endpoint.

In one implementation of this embodiment, wherein in the step of determining whether the behavior of the local NAT is a symmetric NAT by querying a TURN server, the processor 41 is further configured to:

create and send an allocate request message to the TURN server;

receive an allocate response message from the TURN server; wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the allocate response message; and

determine whether the behavior of the local NAT is a symmetric NAT based on the LOCAL-NAT-BEHAVE-RESPONSE attribute carried in the allocate response message.

In one implementation of this embodiment, wherein in the step of determining whether the behavior of the remote NAT is a symmetric NAT by querying the TURN server, the processor 41 is further configured to:

create and send a permission request message to the TURN server, wherein a PEER-NAT-BEHAVE-QUERY attribute is carried in the permission request message;

receive a permission response message from the TURN server, wherein a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the permission response message; and

determine whether the behavior of the remote NAT is a symmetric NAT according to the PEER-NAT-BEHAVE-RESPONSE attribute carried in the permission response message.

In one implementation of this embodiment, wherein the processor 41 is further configured to:

send information of a host candidate address, a server reflexive candidate address which is a translated transport address on a public side of the NAT and a relay candidate address to the receiving endpoint, wherein the information of a host candidate address, a server reflexive candidate address and a relay candidate address is used for communicating with other receiving endpoints.

In one implementation of this embodiment, wherein the processor 41 is further configured to:

send information of a relay candidate address to the receiving endpoint, wherein the information of a relay candidate address is used for communicating with other receiving endpoints.

In one implementation of this embodiment, wherein in the step of determining whether the behavior of the remote NAT is a symmetric NAT being informed by the receiving endpoint, the processor 41 is further configured to:

send an invite message to the receiving endpoint, wherein the invite message indicates that the behavior of the local NAT is a symmetric NAT;

receive a response message which indicates that the behavior of the remote NAT is a symmetric NAT.

In one implementation of this embodiment, wherein in the step of performing a session over the relay to relay candidate pair upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT, the processor 41 further is configured to:

send, upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT, a Session Description Protocol(SDP) offer message including a first relay candidate address which is allocated from a TURN server to the sending endpoint, to the receiving endpoint, wherein a USE-CANDIDATE attribute is carried in the first relay candidate address so as to inform the receiving endpoint to return back a second relay candidate address which is allocated from the TURN server to the receiving endpoint;

receive an SDP answer message including the second relay candidate address from the receiving endpoint;

perform the session by using the first relay candidate address and the second relay candidate address, wherein the relay to relay candidate pair includes the first relay candidate address and the second relay candidate address.

The memory 42 may include a high speed RAM and a non-volatile memory. The processor 41 may be a Central Processing Unit (CPU), or can be Application Specific Integrated Circuit (ASIC), or can be configured to one or more ASIC.

Further, as shown in Fig. 26, there may also include a communication interface 43, configured to complete the communication between the sending endpoints and the servers or other devices.

As shown in Fig. 26, the sending endpoint may also include a disk 44, configured to store the program to be tested and state information of the process of the program to be tested.

Alternatively, in specific implementation, if the memory 42, the processor 41 the communication interface 43 and the disk 44 can be implemented individually, then the memory 42, the processor 41, the communication interface 43 and the disk 44 can be in communication connection via BUS. The BUS can be Industry Standard Architecture (ISA) BUS, Peripheral Component (PCI) BUS or Extended Industry Standard Architecture (EISA) BUS etc. The BUS can be divided into address BUS, data BUS and control BUS etc. For convenient representation, the BUS is only represented by a single thick line, but does not mean there is only one BUS or one kind of BUS.

Alternatively, in specific implementation, if the memory 42, the processor 41, the communication interface 43 and the disk 44 can be integrated in a single chip, then the memory 42, the processor 41 the communication interface 43 and the disk 44 can be in communication connection via internal interface.

The advantages of embodiments of the present invention exist in that: upon determining that both a sending endpoint and a receiving endpoint are behind symmetric NAT then performing a session over a relay to relay candidate pair, thereby eliminating the unnecessary portions of ICE procedures when both endpoints are behind symmetric NAT, resulting in a higher connection establishment speed.

The present invention also provides a non-transitory computer readable storage medium, including computer program codes which when executed by a computer processor cause the compute processor to execute the method for session establishment based on NAT according to embodiments of the present invention.

By the embodiments described above, persons skilled in the art may clearly understand that the present invention may be implemented by software with necessary common hardware. Specifically, the present invention may also be implemented by only hardware. However, the former is the preferred implementation mode. Based on such understanding, the essence of the technical solution of the present invention or the part of that makes a contribution to the prior art may be implemented in the form of software product. The computer software product is stored in a readable storage medium such as a computer floppy disk, a hard disk, or an optical disk, and includes multiple instructions to enable computer equipment (which may be a personal computer, a server, or network equipment) to execute the method described in embodiments of the present invention.

Embodiment 13

This embodiment of the present invention provides a receiving endpoint. This embodiment corresponds to the method of the above embodiment 3, and the same content will not be described.

In this embodiment, the receiving endpoint includes: a processor and a memory coupled to the processor for executing a plurality of instructions present in the memory.

FIG. 27 is a schematic structure diagram of a receiving endpoint according to an embodiment of the present invention. As shown in FIG. 27, there is a memory 52 that stores a plurality of instructions; and a processor 51 coupled to the memory 52

The memory 52, configured to store program. Specifically, the program can includes program code, the program code includes computer operating instruction.

the processor 51 is configured to execute the instructions to:

inform information which indicates that whether behavior of a remote NAT which the receiving endpoint is behind is a symmetric NAT or not to a sending endpoint or a TURN server;

perform a session over a relay to relay candidate pair with the sending endpoint upon determining that behavior of a local NAT which the sending endpoint is behind and the behavior of the remote NAT are a symmetric NAT ; wherein the relay to relay candidate pair is a relay candidate addresses pair allocated from a TURN server to the sending endpoint and the receiving endpoint.

In one implementation of this embodiment, wherein in the step of informing information which indicates that whether behavior of remote NAT is a symmetric NAT or not to a sending endpoint, the processor 51 further is configured to receive an invite message indicating that the behavior of the local NAT is a symmetric NAT from the sending endpoint;

send the response message indicating that the behavior of the remote NAT is a symmetric NAT to a sending endpoint.

In one implementation of this embodiment, wherein in the step of performing a session over the relay to relay candidate pair upon determining that the behaviors of the local NAT and the remote NAT are both a symmetric NAT, the processor 51 is further configured to:

receive a Session Description Protocol(SDP) offer message including a first relay candidate address which is allocated from a TURN server to the sending endpoint, wherein a USE-CANDIDATE attribute is carried in the first relay candidate address so as to inform the receiving endpoint to return back a second relay candidate address which is allocated from the TURN server to the receiving endpoint;

send an SDP answer message including the second relay candidate address to the sending endpoint;

perform the session with the sending endpoint by using the first relay candidate address and the second relay candidate address.

The memory 52 may include a high speed RAM and a non-volatile memory. The processor 51 may be a Central Processing Unit (CPU), or can be Application Specific Integrated Circuit (ASIC), or can be configured to one or more ASIC.

Further, as shown in Fig. 27, there may also include a communication interface 53, configured to complete the communication between the receiving endpoints and servers or other devices.

As shown in Fig. 27, the receiving endpoints may also include a disk 54, configured to store the program to be tested and state information of the process of the program to be tested.

Alternatively, in specific implementation, if the memory 52, the processor 51 the communication interface 53 and the disk 54 can be implemented individually, then the memory 52, the processor 51, the communication interface 53 and the disk 54 can be in communication connection via BUS. The BUS can be Industry Standard Architecture (ISA) BUS, Peripheral Component (PCI) BUS or Extended Industry Standard Architecture (EISA) BUS etc. The BUS can be divided into address BUS, data BUS and control BUS etc. For convenient representation, the BUS is only represented by a single thick line, but does not mean there is only one BUS or one kind of BUS.

Alternatively, in specific implementation, if the memory 52, the processor 51, the communication interface 53 and the disk 54 can be integrated in a single chip, then the memory 52, the processor 51 the communication interface 53 and the disk 54 can be in communication connection via internal interface.

The advantages of embodiments of the present invention exist in that: upon determining that both a sending endpoint and a receiving endpoint are behind symmetric NAT then performing a session over a relay to relay candidate pair, thereby eliminating the unnecessary portions of ICE procedures when both endpoints are behind symmetric NAT, resulting in a higher connection establishment speed.

The present invention also provides a non-transitory computer readable storage medium, including computer program codes which when executed by a computer processor cause the compute processor to execute the method for session establishment based on NAT according to embodiments of the present invention.

Embodiment 14

This embodiment of the present invention provides a TURN server. This embodiment corresponds to the method of the above embodiment 4, and the same content will not be described.

In this embodiment, the TURN server includes: a processor and a memory coupled to the processor for executing a plurality of instructions present in the memory.

FIG. 28 is a schematic structure diagram of a TURN server according to an embodiment of the present invention. As shown in FIG. 28, there is memory 62 that stores a plurality of instructions; and a processor 61 coupled to the memory 62The memory 62, configured to store program. Specifically, the program can includes program code, the program code includes computer operating instruction.

the processor 61 is configured to execute the instructions to:

receive a request message from a sending endpoint;

send a response message to the sending endpoint, wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the response message, or a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the response message, so that the sending endpoint determines whether behavior of a local NAT which the sending endpoint is behind is a symmetric NAT or determines whether behavior of a remote NAT which a receiving endpoint is behind is a symmetric NAT based on the request message and the response message.

In one implementation of this embodiment, wherein the processor 61 is further configured to store the behavior of the local NAT determined by an NAT Behavior Discovery device.

In one implementation of this embodiment, wherein in the step of receiving a request message from a sending endpoint and sending a response message to the sending endpoint, the processor 61 is further configured to:

receive an allocate request message from the sending endpoint;

send an allocate response message to the sending endpoint, wherein a LOCAL-NAT-BEHAVE-RESPONSE attribute is carried in the allocate response message, so that the sending endpoint determines the behavior of the local NAT based on the LOCAL-NAT-BEHAVE-RESPONSE attribute carried in the allocate response message from the TURN server.

In one implementation of this embodiment, wherein in the step of receiving a request message from a sending endpoint and sending a response message to the sending endpoint, the processor 61 is further configured to:

receive a permission request message from the sending endpoint, wherein a PEER-NAT-BEHAVE-QUERY attribute is carried in the permission request message;

send a permission response message to the sending endpoint, wherein a PEER-NAT-BEHAVE-RESPONSE attribute is carried in the permission response message,

so that the sending endpoint determines the behavior of the remote NAT according to the PEER-NAT-BEHAVE-RESPONSE attribute carried in the permission response message.

The memory 62 may include a high speed RAM and a non-volatile memory. The processor 51 may be a Central Processing Unit (CPU), or can be Application Specific Integrated Circuit (ASIC), or can be configured to one or more ASIC.

Further, as shown in Fig. 28, there may also include a communication interface 63, configured to complete the communication between the TURN servers or other devices.

As shown in Fig. 28, the TURN server may also include a disk 64, configured to store the program to be tested and state information of the process of the program to be tested.

Alternatively, in specific implementation, if the memory 62, the processor 61 the communication interface 63 and the disk 64 can be implemented individually, then the memory 62, the processor 61, the communication interface 63 and the disk 64 can be in communication connection via BUS. The BUS can be Industry Standard Architecture (ISA) BUS, Peripheral Component (PCI) BUS or Extended Industry Standard Architecture (EISA) BUS etc. The BUS can be divided into address BUS, data BUS and control BUS etc. For convenient representation, the BUS is only represented by a single thick line, but does not mean there is only one BUS or one kind of BUS.

Alternatively, in specific implementation, if the memory 62, the processor 61, the communication interface 63 and the disk 64 can be integrated in a single chip, then the memory 62, the processor 61 the communication interface 63 and the disk 64 can be in communication connection via internal interface.

The present invention also provides a non-transitory computer readable storage medium, including computer program codes which when executed by a computer processor cause the compute processor to execute the method for determining behavior of NAT according to embodiments of the present invention.

Embodiment 15

This embodiment of the present invention provides an STUN. This embodiment corresponds to the method of the above embodiment 5, and the same content will not be described.

In this embodiment, the STUN includes: a processor and a memory coupled to the processor for executing a plurality of instructions present in the memory.

FIG. 29 is a schematic structure diagram of an STUN according to an embodiment of the present invention. As shown in FIG. 29, there is memory 72 that stores a plurality of instructions; and a processor 71 coupled to the memory 72

The memory 72, configured to store program. Specifically, the program can includes program code, the program code includes computer operating instruction.

the processor 71 is configured to execute the instructions to:

receive an STUN binding request message from an NAT Behavior Discovery device;

return an STUN binding response message, to the NAT Behavior Discovery device, wherein a NAT address is carried in the STUN binding response message and a NAT-BEHAVE attribute is included in the NAT address, so that the NAT Behavior Discovery device can determine the behavior of the NAT. The memory 72 may include a high speed RAM and a non-volatile memory. The processor 71 may be a Central Processing Unit (CPU), or can be Application Specific Integrated Circuit (ASIC), or can be configured to one or more ASIC.

Further, as shown in Fig. 29, there may also include a communication interface 73, configured to complete the communication between the STUNs and servers or other devices.

As shown in Fig. 29, the STUN may also include a disk 74, configured to store the program to be tested and state information of the process of the program to be tested.

Alternatively, in specific implementation, if the memory 72, the processor 71 the communication interface 73 and the disk 74 can be implemented individually, then the memory 72, the processor 71, the communication interface 73 and the disk 74 can be in communication connection via BUS. The BUS can be Industry Standard Architecture (ISA) BUS, Peripheral Component (PCI) BUS or Extended Industry Standard Architecture (EISA) BUS etc. The BUS can be divided into address BUS, data BUS and control BUS etc. For convenient representation, the BUS is only represented by a single thick line, but does not mean there is only one BUS or one kind of BUS.

Alternatively, in specific implementation, if the memory 72, the processor 71, the communication interface 73 and the disk 74 can be integrated in a single chip, then the memory 72, the processor 71 the communication interface 73 and the disk 74 can be in communication connection via internal interface.

The present invention also provides a non-transitory computer readable storage medium, including computer program codes which when executed by a computer processor cause the compute processor to execute the method for determining behavior of NAT according to embodiments of the present invention.

Embodiment 16

This embodiment of the present invention provides an NAT Behavior Discovery device. This embodiment corresponds to the method of the above embodiment 6, and the same content will not be described.

In this embodiment, the NAT Behavior Discovery device includes: a processor and a memory coupled to the processor for executing a plurality of instructions present in the memory.

FIG. 30 is a schematic structure diagram of an NAT Behavior Discovery device according to an embodiment of the present invention. As shown in FIG. 30, there is memory 82 that stores a plurality of instructions; and a processor 81 coupled to the memory 82.

The memory 82, configured to store program. Specifically, the program can includes program code, the program code includes computer operating instruction.

the processor 81 is configured to execute the instructions to:

send an STUN binding request message to an STUN server;

receive an STUN binding response message from the STUN server, wherein a NAT address is carried in the STUN binding response message and a NAT-BEHAVE attribute is carried in the NAT address;

determine behavior of a local NAT which a sending endpoint is behind based on the NAT-BEHAVE attribute included in the NAT address; and

update the behavior of the local NAT, to the TRUN server.

In one implementation of this embodiment, wherein the processor 81 is further configured to employ a remote NAT Discovery algorithm to determine behavior of a remote NAT which a receiving endpoint is behind based on an NAT-BEHAVE attribute included in a server reflexive candidate address of the receiving endpoint, wherein the server reflexive candidate address is a translated transport address on a public side of the NAT; and

update the behavior of the remote NAT, to the TRUN server. In one implementation of this embodiment, a remote NAT Discovery algorithm is employed to determine and update the behavior of the receiving endpoint NAT to the TURN server through the NAT-BEHAVE attribute.

The memory 82 may include a high speed RAM and a non-volatile memory. The processor 81 may be a Central Processing Unit (CPU), or can be Application Specific Integrated Circuit (ASIC), or can be configured to one or more ASIC.

Further, as shown in Fig. 30, there may also include a communication interface 83, configured to complete the communication between the NAT Behavior Discovery device and servers or other devices.

As shown in Fig. 30, the NAT Behavior Discovery device may also include a disk 84, configured to store the program to be tested and state information of the process of the program to be tested.

Alternatively, in specific implementation, if the memory 82, the processor 81 the communication interface 83 and the disk 84 can be implemented individually, then the memory 82, the processor 81, the communication interface 83 and the disk 84 can be in communication connection via BUS. The BUS can be Industry Standard Architecture (ISA) BUS, Peripheral Component (PCI) BUS or Extended Industry Standard Architecture (EISA) BUS etc. The BUS can be divided into address BUS, data BUS and control BUS etc. For convenient representation, the BUS is only represented by a single thick line, but does not mean there is only one BUS or one kind of BUS.

Alternatively, in specific implementation, if the memory 82, the processor 81, the communication interface 83 and the disk 84 can be integrated in a single chip, then the memory 82, the processor 81 the communication interface 83 and the disk 84 can be in communication connection via internal interface.

The present invention also provides a non-transitory computer readable storage medium, including computer program codes which when executed by a computer processor cause the compute processor to execute the method for determining behavior of NAT according to embodiments of the present invention.

Embodiment 17

This embodiment of the present invention further provides a system for performing a session based on NAT. This embodiment corresponds to the above embodiment 7 ~ 11, and the same content will not be described.

In this embodiment, the system for performing a session based on NAT includes: one or more clients as described in the embodiment 7 and embodiment 8, and one or more TRUN servers as described in the embodiment 9, and one or more STUN servers as described in the embodiment 10.

In this embodiment, the system for performing a session based on NAT may further includes:

one or more device as described in the embodiment 11.

Figure 31 is a schematic diagram of the system in accordance with an embodiment of the present invention. As shown in Figure 31, wherein,

The system includes a private network A with two sending endpoints, (SIP client A and SIP client B) with private IP addresses 10.0.0.1 and 10.0.0.2. This network has a configured NAT with an external IP address as 2.2.2.1. Similarly a second private network with a receiving endpoint(SIP client C) with private IP address 10.0.0.1 has a NAT with a configured external IP address as 3.3.3.1.

The SIP client A (10.0.0.1–private network A) attempts to call SIP client C (10.0.0.1 - private network B). How a SIP client determines the translated IP address (3.3.3.1) of SIP client C is out of the scope of this invention. Upon determining the IP address of SIP client C, it simply invokes the ICE module to find the best available path for data transmission. Towards the end of this procedure a table will be built in the TURN server that specifies that both IP addresses 2.2.2.1 and 3.3.3.1 represent symmetric NATs. The number of ICE procedures that this call performs is represented in embodiment 1 and 2.

Hereafter any call between the clients in private network A and private network B makes use of this information in the TURN table to reduce the overhead in ICE procedures when both endpoints are behind symmetric NAT.

It can be seen from the above embodiment that: when two endpoints behind the symmetric NAT attempts to call each other, the call connectivity establishment will be faster and the data can start flowing between the endpoints faster. The major effect of the invention is the significant reduction in the call establishment delay as perceived by the user.

For example, the time duration for normal ICE traversal:

Connectivity checks-> relay-relay is scheduled after 500ms (100ms for each pair and there are 5 other pairs before relay-relay)

The peak time RTT = 250ms
Hence relay-relay(for 1 media component) = 750ms
Hence relay-relay for 4 components(1 audio + 3 m-lines) = 3000ms
Total time before : 3000ms

The time duration with the proposed solution:
Total time now: 250ms (direct relay-relay selection)

It should be understood that each of the parts of the present invention may be implemented by hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods may be realized by software or firmware that is stored in the memory and executed by an appropriate instruction executing system. For example, if it is realized by hardware, it may be realized by any one of the following technologies known in the art or a combination thereof as in another embodiment: a discrete logic circuit having a logic gate circuit for realizing logic functions of data signals, application-specific integrated circuit having an appropriate combined logic gate circuit, a Programmable Gate Array (PGA), and a field programmable gate array (FPGA), etc.

The description or blocks in the flowcharts or of any process or method in other manners may be understood as being indicative of comprising one or more modules, segments or parts for realizing the codes of executable instructions of the steps in specific logic functions or processes, and that the scope of the embodiments of the present invention comprise other implementations, wherein the functions may be executed in manners different from those shown or discussed, including executing the functions according to the related functions in a substantially simultaneous manner or in a reverse order, which should be understood by those skilled in the art to which the present invention pertains.

The logic and/or steps shown in the flowcharts or described in other manners here may be, for example, understood as a sequencing list of executable instructions for realizing logic functions, which may be implemented in any computer readable medium, for use by an instruction executing system, device or apparatus (such as a system including a computer, a system including a processor, or other systems capable of extracting instructions from an instruction executing system, device or apparatus and executing the instructions), or for use in combination with the instruction executing system, device or apparatus.

The above literal description and drawings show various features of the present invention. It should be understood that those skilled in the art may prepare appropriate computer codes to carry out each of the steps and processes as described above and shown in the drawings. It should be also understood that all the terminals, computers, servers, and networks may be any type, and the computer codes may be prepared according to the disclosure to carry out the present invention by using the apparatus.

Particular embodiments of the present invention have been disclosed herein. Those skilled in the art will readily recognize that the present invention is applicable in other environments. In practice, there exist many embodiments and implementations. The appended claims are by no means intended to limit the scope of the present invention to the above particular embodiments. Furthermore, any reference to “a device to…” is an explanation of device plus function for describing elements and claims, and it is not desired that any element using no reference to “a device to…” is understood as an element of device plus function, even though the wording of “device” is included in that claim.

Although a particular embodiment has been shown and the present invention has been described, it is obvious that equivalent modifications and variants are conceivable to those skilled in the art in reading and understanding the description and drawings. Especially for various functions executed by the above elements (portions, assemblies, apparatus, and compositions, etc.), except otherwise specified, it is desirable that the terms (including the reference to “device”) describing these elements correspond to any element executing particular functions of these elements (i.e. functional equivalents), even though the element is different from that executing the function of an exemplary embodiment or embodiments illustrated in the present invention with respect to structure. Furthermore, although the a particular feature of the present invention is described with respect to only one or more of the illustrated embodiments, such a feature may be combined with one or more other features of other embodiments as desired and in consideration of advantageous aspects of any given or particular application.