WO2006079954A1

WO2006079954A1 - Method and terminal for selecting a communication path depending on the presence of nat devices

Info

Publication number: WO2006079954A1
Application number: PCT/IB2006/050217
Authority: WO
Inventors: Xiaohui Jin; Xiaoling Shao; Bo Liu
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2005-01-31
Filing date: 2006-01-20
Publication date: 2006-08-03

Abstract

The present invention discloses a method for selecting different communication paths in a terminal, including the steps of: judging whether the networks where the initiator terminal and a called terminal locate respectively have NAT devices or not; and selecting the corresponding communication path for communication operation based on the judged result. According to the present invention, the services restricted by the types and the number of NAT devices can be extended.

Description

METHOD AND TERMINAL FOR SELECTING A COMMUNICATION PATH DEPENDING ON THE PRESENCE OF NAT DEVICES

FIELD OF THE INVENTION

This invention relates to communication field, more particularly to a method for selecting different communication paths and to a communication terminal for implementing said method.

BACKGROUND OF THE INVENTION

In recent years, wireless overlay network becomes a hot research topic. Ideally every kind of service, including VoIP, WWW, FTP and so on, should be supported in wireless overlay network. However, some kinds of service supported in a certain network may not be supported in another network, therefore the type of service supported in a wireless overlap network is restricted due to complicated network topologies, different communication protocols, different interconnecting methods, and other factors. At the same time, Network Address Translation (NAT) is one important restriction limiting the type of services between two communication terminals in the Internet. To support different application, different application gateway has to be added in NAT device. For example, to support VoIP, a VoIP gateway should be added in NAT device. This requirement severely limits the universality and scalability of NAT devices. If there is a NAT device between two communication terminals, the only way to set up connection is that the one behind NAT device starts setup connection request. If not, another one doesn't know where its peer is. If both of them are behind NAT device, it is impossible to set up connection between them without 3^rd party's help.

In general, different networks are deployed independently, it is very possible to have different types of NAT device in wireless overlay network, one or several NAT devices between two terminals. This complicated topology and NAT device type severely limit the availability and scalability of services.

Therefore, there requires a method for extending those services restricted by types and the number of NAT devices.

OBJECT AND SUMMARY OF THE INVENTION

It is the object of the present invention to provide a method and terminal to extend those services restricted by types and the number of NAT devices.

To fulfill such an object, the present invention provides a method for selecting different communication paths in a terminal, comprising the steps of: judging whether the networks where the initiator terminal and a called terminal respectively locate have NAT devices or not; and selecting the corresponding communication path for communication service based on the judged result.

The present invention further provides a terminal, which comprising: judge means for judging whether the networks where the initiator terminal and a called terminal respectively locate have NAT devices or not; and selection means for selecting the corresponding communication path for communication service based on the judged result.

Those services restricted by types and the number of NAT devices can be extended according to the invention.

The other objects and effects of the present invention will be more clear and comprehensible by referring to the following description and claims taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The preferred embodiments is explained in further detail with reference to the accompanying drawings wherein :

Figure 1 is a diagram that shows network topology according to an embodiment of the present invention;

Figure 2 is a flowchart that shows the position-inquiring procedure according to an embodiment of the present invention; Figure 3 is a flowchart that shows the position-inquiring procedure according to an embodiment of the present invention;

Figure 4 is a flowchart that shows the position-inquiring procedure according to an embodiment of the present invention;

Figure 5 is a flowchart that shows VoIP communication process under the situation that there is no NAT device between two terminals;

Figure 6 is a flowchart that shows setup VoIP communication process when the initiator terminal is not behind NAT whereas the called terminal is behind NAT;

Figure 7 is a flowchart that shows VoIP communication process implemented by the relaying of IMS when VoIP connection cannot be directly set upped between the initiator terminal and the called terminal; Figure 8 is a diagram that illustratively shows the user terminal according to an embodiment of the present invention.

Throughout the drawings, the same reference numerals indicate similar or corresponding features or functions.

DETAILED DESCRIPTION OF THE INVENTION

Figure 1 is a diagram that shows the network topology according to one of the embodiments according to the present application.

As shown in Figure 1, the network topology 100 includes: wireless local area network (WLAN) 11 including terminal UE_A, cellular network 12 including terminal UE_B, cellular network 13 including terminal UE_C, wireless local area network 14 including terminal UE_D, and Internet 16 including Instant Messaging Server (IMS) 15.

IMS is taken herein as an example to illustrate the specific embodiment of the present invention, in other words, IMS is used to judge whether the networks where the called terminal locates has NAT devices, and to implement communication operation between the two terminals through relaying of the IMS server when judging that the networks where two terminals respectively locate both have NAT devices. Obviously, those skilled in the art should understand that the present invention is not limited to this point, but HTTP server, remote logon (Telnet) server or the like can also be used to judge whether the network where the called terminal locates has NAT devices or not, and to implement the communication operation between the two terminals through relaying of HTTP server, remote logon (Telnet) server or the like when judging the networks where two terminals respectively locate both have NAT devices. Obviously, those skilled in the art should further understand that the network topology is merely exhibitive to facilitate illustration, that is, networks 11-14 can be other types of networks, network 16 can also be reachable networks such as enterprise network and telecom network; Internet 16 may be absent, in other words, IMS 15 can also position at wireless local area network 11, or cellular network 12, or cellular networkl3, or wireless local area network 14.

Wherein, wireless local area network 11 and cellular network 12 include generic NAT devices, and cellular network 13 and wireless local area network 14 exclude NAT devices.

In the present embodiment, NAT devices and user terminal equipments support Instant Messaging (IM) service.

IMS 15 in Internet 16 has a public IP address, namely global IP address, which has an IP address of 210.22.172.66, for example. According to one of the embodiments of the present invention, there are three kinds of IMS.

The first is legacy IMS, named as EVIS A herein, which does not support any special inquiry out of legacy instant messaging system. For example, terminal UE_A sends an inquiry packet to IMS to inquire terminal UE_B's IP address, but IMS doesn't understand the meaning and just drops the packet.

The second, named as IMS B herein, is capable of replying terminal UE_B's

IP address to terminal UE_A if receiving an inquiry packet about UE_B's IP address from terminal UE_A. The terminal UE_B's IP address can be its own IP address, but not necessary. It also can be an IP address assigned by NAT device in this connection. The third, named as IMS C herein, is capable of knowing whether the

Instant Messaging (IM) terminals such as terminal UE_A or terminal UE_B are behind NAT. If so, two IP addresses are stored in the database of the IMS, one is this terminal's own IP address and another one is the IP address assigned by NAT. As an option, the type of NAT. e.g., supporting VoIP or not, support FTP or not, can be deduced by the EVIS through exchanging with the terminals.

VoIP communication is taken as an example herein to illustrate specific embodiment. Obviously, those skilled in the art should understand that the present invention is not limited to this point.

According to the present invention , the functions implemented by the terminals include: sending inquiry packet to IMS to inquire its peer's IP address; sending inquiry packet to its peer to inquire its IP address; updating its address record on IMS if logged on IMS; brushing or re-logging on IMS to update its address record on IMS if its address changes; keeping the connection with IMS active after its logon, and releasing the connection after its logout; encapsulating VoIP packet into IM packet; and supporting one or several encapsulate methods, and negotiating between terminals if there are different encapsulate methods. The present invention does not require the terminal kept logon IMS to keep IMS recording address information.

The specific structure of the terminal will be described detailedly below.

According to the present invention, before set up connection and perform

VoIP communication, the first thing for the initiator is to acquire whether NAT exists and how many NAT devices exist along the path between these two terminals. The number of

NAT devices influences the setup connection procedure and the connection path between two terminals.

According to the present invention, when a user, e.g. a user with terminal UE_A in Figure 1, initiates a voice call, he inputs his peer's identity, e.g., Mobile Station International ISDN number (MSISDN) or e-mail account, in terminal UE_A's dial panel, a daemon application intercepts this information and initiates an inquiry process to IMS to inquire the current location information of its peer, for example, terminal UE_B. The information carried in inquiry IM packet can be MSISDN, e-mail account, IM account, or any other identifier that can be used to identify the peer. Figure 2 is a flowchart that shows an inquiry location process according to the present invention, wherein IMS belongs to IMS A.

According to one of the embodiments of the present invention, before inquiring position, the initiator terminal UE_Y and the called terminal UE_X firstly logon IMS 15 and keep their connection with IMS 15 active after their logon, as shown in step S201.

When a user inputs peer terminal UE_X's identity such as MS ISDN or e-mail account in terminal UE_Y, terminal UE_Y sends inquiry IM packet to IMS 15 to inquire IP address of its peer terminal UE_X and locally starts a timer for resending the inquiry IM packet to IMS 15 when response IM packet to reply the inquiry IM packet sent from IMS 15 is not received in defined time, as shown in step

S202.

As for IMS A, since it does not support any special inquiry out of legacy instant messaging system, terminal UE_Y will not receive response IM packet to reply the inquiry IM packet from IMS 15.

Thus, when the timer overflows, terminal UE_Y resends inquiry IM packet to IMS 15 to inquire its peer terminal UE_X's IP address and relocates the timer, as shown in step S203. Similarly, terminal UE_Y will not receive response IM packet to reply the inquiry IM packet from IMS 15.

After several inquiry attempt fail, such as, 4 times, terminal UE_Y decides to have the last try and send another inquiry IM packet to IMS 15 again to inquire the IP address of the terminal UE_X, as shown in step S204. Obviously, terminal UE_Y cannot receive response IM packet to reply the inquiry IM packet from IMS 15, either.

At this time, terminal UE_Y knows that IMS 15 belongs to IMS A, and that it does not support any special inquiry out of legacy Instant Messaging system.

Therefore, on seeing terminal UE_X logged on IMS 15 .terminal UE_Y directly sends inquiry IM packet to terminal UE_X to inquire its IP address, as shown in step S205.

If terminal UE_Y knows IMS 15 belongs to IMS A, it may not send inquiry IM packet to EVIS to inquire its peer's IP address but directly send inquiry IM packet to its peer to inquire the its IP address to save time.

Note , in most of the legacy IMS systems, terminal UE_Y sends a packet to IMS firstly, and IMS forwards it to terminal UE_X. In certain IMS systems, message is also forwarded by network according to the inner routing protocols between UE_Y and UE_X without passing IMS.

After receive inquiry IM packet, terminal UE_X replies to terminal UE_Y with a response IM packet carrying terminal UE_X's IP address, as shown in step S206. Similarly, attention should be paid, in most legacy IM systems, terminal

UE_X sends an inquiry IM packet to IMS firstly, and IMS forwards it to UE_Y.

Under the situation of appropriate configuration, if terminal UE_X is not behind NAT devices, the IP address should be global addressed, i.e., the IP address should be a public IP address , for example 210.72.234.162; if terminal UE_X is behind NAT devices, its IP address should be private IP address, for example, 192.168.12.12,

172.16.3.3 and the like. After extracting IP address of terminal UE_X from response IM packet, terminal UE_Y knows whether the terminal UE_X is behind NAT device. Combining with terminal UE_Y's situation, i.e., whether it is behind NAT devices, different methods can be used to set up VoIP connection. Note, terminal UE_Y may judge whether itself is behind NAT devices and whether the NAT devices support VoIP via many methods, which however are familiar to those skilled in the art and will not be detailedly described herein.

Figure 3 is a flowchart that shows another inquiry location processes according to the present invention, wherein IMS belongs to IMS B. According to an embodiment of the present invention, before inquiring position, the initiator terminal UE_Y and the called terminal UE_X should be logged on IMS 15 firstly and keep their connection with IMS active after their logon, as shown in step S 301.

When a user inputs the terminal UE_X's identity such as MSISDN or e-mail account in terminal UE_Y, terminal UE_Y sends inquiry IM packet to IMS 15 to inquire the IP address of peer terminal UE_X and locally starts a timer for resending the inquiry IM packet to IMS 15 when response IM packet to reply inquiry

IM packet sent from IMS 15 is not received in defined time, as shown in step S302.

As for IMS B, since it supports the special inquiry out of legacy instant messaging system, it sends response IM packet for the inquiry IM packet to user terminal UE_Y after receiving the inquiry IM packet from terminal UE_Y about the

IP address of terminal UE_X, wherein the response IM packet includes the IP address when terminal UE_X is logged on IMS, as shown in step S3O3.

However, since IP address of terminal UE_X obtained based on step S3O3 is certainly a public IP address, it is impossible to judge whether terminal UE_X is behind NAT. As a result, terminal UE_Y sends inquiry IM packet to terminal UE_X about its actual IP address, as shown in step S304.

Note, in most of the situations, terminal UE_Y sends packet to IMS firstly, and IMS forwards it to terminal UE_X. In some IMS system, message is also forwarded by network according to the inner routing protocols between UE_Y and

UE_X without passing IMS.

After receiving the inquiry IM packet about its actual IP address sent from terminal UE_Y, terminal UE_X replies a response IM packet carrying its actual IP address to terminal UE_Y, as shown in step S305.

Similarly, attention should be paid, in most of the cases , terminal UE_X sends packet to IMS firstly, and IMS forwards it to terminal UE_Y.

Then, terminal UE_Y compares the two IP addresses received from IMS and terminal UE_X. If they are the same, it means that terminal UE_X is not behind NAT; if not the same, it means that terminal UE_X is behind NAT. Combining with its situation, that is, whether terminal UE_Y is behind NAT devices, different methods can be used to set up VoIP connection.

Figure 4 is a flowchart that shows another inquiry location process according to the present invention, wherein IMS belongs to IMS C.

According to an embodiment of the present invention, before inquiring position, the initiator terminal UE_Y and the called terminal UE_X is firstly logged on IMS 15 and keep their connection with IMS 15 active after their logon, as shown in step S401. Note , at this point, after the called terminal UE_X has updated its position information on IMS 15, it is unnecessary to keep the connection with IMS 15 active after its logon.

After a user inputs peer terminal UE_X's identity such as MSISDN or e-mail account in terminal UE_Y, terminal UE_Y sends a inquiry IM packet to IMS 15 to inquire its terminal UE_X's IP address and locally starts a timer for resending the inquiry IM packet to IMS 15 when response IM packet to reply inquiry IM packet sent from IMS 15 is not received in defined time, as shown in step S402.

As for IMS C, since it knows whether Instant Messaging terminal such as terminal UE_A or terminal UE_B is behind NAT, IMS 15 directly replies terminal UE_Y with terminal UE_X's position formation on receiving inquiry IM packet from terminal UE_Y about terminal UE_X's IP address, as shown in step S403.

If terminal UE_X is not behind NAT, IMS replies terminal UE_Y with position information including terminal UE_X's IP address and the information of

"terminal UE_X is not behind NAT"; if the terminal UE_X is behind NAT devices, IMS replies terminal UE_Y with the position information including the information of

"UE_x is behind NAT". As an option, the position information that IMS replies to terminal UE_Y can include the actual IP address and assigned IP address by NAT device. Combining with terminal UE_Y's situation, that is, whether terminal UE_Y is behind NAT devices, different methods can be used to set up VoIP connection.

If terminal UE_Y knows from, e.g., the assigned IP address that it is not behind NAT, that is, there is no NAT between terminal UE_Y and IMS, and finds through the previous position discovery process that there is no NAT between terminal UE_X and IMS, for example, when terminal UE_Y is terminal UE_C in Figure 1 and terminal UE_X is terminal UE_D in Figure 1, a VoIP communication can be directly set upped between terminal UE_Y and UE_X.

Figure 5 is a flowchart that shows VoIP communication process performed under the situation that there is no NAT device between two terminals; as shown in

Figure 5, terminal UE_Y initially knows that there does not exist NAT device between terminal UE_Y and terminal UE_X through the previous inquiry location process and its assigned IP address.

Therefore, terminal UE_Y directly sends VoIP setup request to terminal UE_X to perform VoIP communication between them, as shown in step S501.

After receiving VoIP setup request sent from terminal UE_Y, if allowed to accept the request, terminal UE_X should send VoIP setup acceptance information to terminal UE_Y, as shown in step S502.

In this way, VoIP communication can be carried out between terminal UE_Y and terminal UE_X, as shown in step S503.

In the above cases, IMS is not involved in VoIP communication.

Note , terminal UE_Y can also send an IM packet to terminal UE_X to request initiation of VoIP setup process by terminal UE_X, which is obviously not necessary. When terminal UE_Y knows from, e.g., the assigned IP address, that it is behind NAT, or in other words, there is NAT device between terminal UE_Y and IMS, and finds that there is no NAT device between terminal UE_X and IMS through the previous position discovery process, for example, when terminal UE_Y is terminal UE_A in Figure 1 and terminal UE_X is terminal UE_D in Figure 1, the terminal UE_Y may send VoIP setup request to terminal UE_X, as terminal UE_Y knows the public IP address of terminal UE_X.

In this scenario, VoIP communication process between terminal UE_Y and terminal UE_X is the same as that in the situation that there is no NAT device between terminal UE_Y and terminal UE_X as shown in Figure 5, which should be quite clear as for those skilled in the art.

Note, in this scenario, only terminal UE_Y can start the VoIP setup process, and terminal UE_Y cannot send an IM packet to terminal UE_X to request terminal UE_X to start the VoIP setup process, as terminal UE_X does not know terminal UE_Y's public IP address assigned by NAT.

When terminal UE_Y knows from, e.g., its assigned IP address that itself is not behind NAT devices, that is, there is no NAT device between terminal UE_Y and IMS, and finds there is NAT device between terminal UE_X and IMS from the previous terminal location discovery process, for example, when terminal UE_Y is terminal UE_C in Figure 1 and terminal UE_X is terminal UE_B in Figure 1, because terminal UE_Y doesn't know terminal UE_X's assigned public IP address by NAT but terminal UE_Y has a public IP address, there should be a shift of communication setup right, i.e. , the shift of initiator and called party, and terminal UE_X starts VoIP setup request first.

Figure 6 is a flowchart that shows setup VoIP communication process according to an embodiment of the present invention.

As shown in Figure 6, in the present embodiment, terminal UE_Y is not behind NAT, whereas terminal UE_X is behind NAT, and the NAT terminal supports

VoIP. Terminal UE_Y firstly knows that there is no NAT device between terminal UE_Y and IMS, and there exists NAT device between terminal UE_X and IMS, and the NAT device supports VoIP according to the inquiry location process and the assigned IP address as described previously. Therefore, terminal UE_Y sends to terminal UE_X a shift_right IM packet carrying the message of "please set up a VoIP connection with terminal UE_Y" through IMS , as shown in step S601.

After receiving the shift_right IM packet, if appropriate, terminal UE_X sends VoIP setup request directly to terminal UE_Y without passing IMS, as shown in step S603.

Optionally, terminal UE_Y sends a shift_right_ack EVI packet to terminal UE_X through IMS before sending the VoIP setup request, as shown in step S602.

If appropriate, terminal UE_Y accepts the VoIP setup request, and terminal UE_X initiates VoIP communication, as shown in step S604.

Those skilled in the art can see that the VoIP communication does not involve IMS at this moment. The communication path therebetween is thus shown in imaginary line in Figure 1. Note , the above cases are based on the assumption that NAT devices all support VoIP communication. When NAT devices do not support VoIP communication in the above cases, the method detailed described below can be applied.

Sometimes wrong network configuration may introduce additional setup delay. For example , when IMS belongs to IMS A, according to the previous illustration, terminal UE_Y directly sends inquiry IM packet to terminal UE_X to inquire its IP address. When UE_X is behind NAT, in the case that the network configuration is right, terminal UE_X's IP address in the response IM packet sent back to terminal UE_Y should be private IP address rather than public IP address. However, when the network configuration is wrong, it does happen in the real world, terminal UE_X's IP address in response IM packet sent back to terminal UE_Y is a public IP address rather than a private IP address. At this moment, if terminal UE_Y cannot distinguish the terminal UE_X behind NAT due to its wrong "public" IP address, when terminal UE_Y is not behind or behind NAT, and NAT devices support VoIP, VoIP setup request will sent to terminal UE_X. Obviously, at this moment, terminal

UE_X will not reply the VoIP setup request, that is, the several attempts of terminal UE_Y to set up VoIP connection with terminal UE_X will fail, this lead to additional setup delay.

However, because the initiator terminal can see its peer's "online" status, it is reasonable for terminal UE_Y to deduce the result that it can surely set up VoIP connection with terminal UE_X through IMS. After that delay, terminal UE_Y can use the method detailed described below to set up VoIP connection.

Note, the terminal's "online" information and/or presence information can be got according to legacy IM systems operation. No additional modification is needed for legacy IM system.

Sometimes some networks are configured to block packets sourced from some special IP addresses, firewall used in some corporate environment has such function, for example. In this scenario, even no or only one NAT exists between two terminals, no VoIP connection can be set upped. However, if the UE behind firewall is reachable from IMS, using the method described below, VoIP connection can be set upped through the EVIS 's relaying. Figure 7 is a flowchart that shows another embodiment to implement VoIP communication process according to the present invention, wherein VoIP connection cannot be directly setup between terminal UE_Y and terminal UE_X.

Such a situation that VoIP connection cannot be directly set upped between terminal UE_Y and terminal UE_X but VoIP communication is implemented through the IMS's relaying includes but is not limited to:

Terminal UE_Y is behind NAT device, and terminal UE_X is also behind NAT device;

Terminal UE_X has no NAT device therebefore, but terminal UE_Y is behind NAT device that does not support VoIP; Terminal UE_Y has no NAT device therebefore, but terminal UE_X is behind NAT device that does not support VoIP;

Due to wrong network configuration, terminal UE_Y thinks by mistake that terminal UE_X actually behind NAT has public IP address and thus sends VoIP setup request to terminal UE_X, but several attempts fail while terminal UE_X appears online in IM system.

Since networks are configured to block packets sourced from some special IP addresses, even no or only one NAT exists between two UEs, no VoIP connection can be set upped therebetween directly. However, the UE behind firewall is reachable from IMS.

As shown in Figure 7, first , after, for example, the described inquiry location process, terminal UE_Y knows the fact that itself and terminal UE_X cannot directly setup VoIP connection and can only setup VoIP connection with 3^rd party's help, as shown in step S701.

Therefore, terminal UE_Y sends an IM packet encapsulating VoIP request information to terminal UE_X to inform that it want to set up VoIP connection through IMS relaying, as shown in step S703.

Note, in most of the cases, terminal UE_Y sends firstly IM packet encapsulating VoIP request information to IMS, and IMS forwards the packet to terminal UE_X.

Optionally, if there are various encapsulating methods between terminal UE_Y and terminal UE_X to encapsulate VoIP packet into IM packet, the two terminals negotiate the VoIP encapsulating method before a specific encapsulating VoIP step, namely step S703, as shown in steps 702.

On receiving the IM packet encapsulating VoIP request information, if appropriate, terminal UE_X replies an IM packet encapsulating VoIP request information to terminal UE_Y indicating that it accepts the request to setup VoIP connection through the IMS's relaying and is ready to receive VoIP packets encapsulated in IM packets, as shown in step S704.

Similarly, attentions should be paid, in most of the cases, terminal UE_X sends IM packet encapsulating VoIP response information to IMS firstly, and IMS forwards the packet to terminal UE_Y.

After receiving the EVI packet encapsulating VoIP response information, terminal UE_Y knows it is possible to setup VoIP connection with terminal UE_X through the IMS's relaying. Thus, terminal UE_Y and terminal UE_X perform VoIP communication through the IMS's relaying, as shown in step S705.

The specific detail is, terminal UE_Y encapsulates all its VoIP packets into IM packet, that is, the VoIP packet is now the pay load of EVI packet, the destination filed of the EVI packet filled with UE_X' s IM identifier.

Then, terminal UE_Y sends these IM packets encapsulating VoIP to IMS.

Next, IMS forwards these IM packets to terminal UE_X,in which the IP header of EVI packets forwarded to terminal UE_X is different from that of the IM packets sent by terminal UE_X to EVIS, but the payload keep unchanged. After receiving these IM packets encapsulating VoIP, terminal UE_X strips off the IM header and get the VoIP packet, which is sent to appropriate application.

The whole VoIP packet, including its IP header and payload, can be encapsulated in EVI packet. The encapsulation of VoIP and communication process may obeys the international standard or some special solution, for example, the payload of VoIP packet includes User Datagram Protocol (UDP) header, Real time Transport

Protocol (RTP) header, and digitalized voice.

Optionally, to improve the transmission efficiency, the VoIP IP header can be stripped off and not encapsulated in IM packets. Only VoIP payload is encapsulated in IM packets.

Those skilled in the art can see that IMS is involved in VoIP communication at this point. The communication path therebetween then is shown in the lines in Figure 1. Figure 8 is diagram illustratively shows user terminal according to an embodiment of the present invention.

As shown in Figure 8, terminal 80 includes judge means 85 for judging whether the networks where the initiator terminal and the called terminal respectively locate have NAT devices or not, and selection means 84 for selecting the corresponding communication path for communication operation based on the judged result.

Terminal 80 further includes communication operation means 87, when judge means 85 judges that the networks where the initiator terminal and called terminal respectively locate have no NAT devices , or that the network where the initiator terminal locates has NAT devices whereas the network where the called terminal locates has no NAT devices, the selection means 84 controls the communication operation means 87 to directly communicate with the called terminal.

Terminal 80 further comprises a relaying request means 86, when judge means 85 judges that the network where the initiator terminal locates has no NAT whereas the network where the called terminal locates has NAT, the selection means

84 controls the relaying request means 86 to request a server to exchange role between the initiator and the called, so as to make the called terminal initiate a call to the initiator terminal for communication operation; or when judge that the networks where the initiator terminal and called terminal respectively locate have NAT devices, or when the communication operation means 87 informs the judge means 85 that the direct communication operation with user terminal fails, the selection means 84 controls the relaying request means 86 to request a server for relaying service, to make the initiator terminal and called terminal perform communication operation through the server. Terminal 80 may further include a request means 83, the judge means 85 through the request means 83, request a server to judge whether the networks where the initiator terminal and called terminal locate respectively have NAT devices. Obviously, those skilled in the art should understand terminal 80 may further include other means, for example, encapsulation/decapsulation means between the communication operation means 87 and the relaying request means 86 to provide an encapsulation/decapsulation function for data packet. According to an embodiment of the present invention, the communication operation means 87 is VoIP means, the request means 83, the relaying request means 86 is Instant Messaging means.

Obviously, those skilled in the art should understand, the communication operation means 87 can also be FTP means or the like, and request means 83, relaying request means 86 can also be Tenlet client terminal, HTTP client terminal or the like.

There are many other modification and variation within the concept and scope of the present invention. It is understood that the present invention is not limited to the specific embodiment, and the scope of the present invention should be limited by the Claims enclosed herewith.

Claims

CLAIMS:

1. A method for selecting different communication paths in a terminal, comprising the steps of: judging whether networks where the initiator terminal and a called terminal respectively locate have NAT (Network Address Translation) devices or not; and selecting a corresponding communication path for communication operation based on the judged result.

2. The method according to claim 1, wherein the select step includes selecting the communication operation directly with the called terminal, if judging that the networks where the initiator terminal and the called terminal respectively locate have no NAT devices.

3. The method according to claim 1, wherein the select step includes selecting the communication operation directly with the called terminal, if judging that the network where the initiator terminal locates has NAT devices whereas the network where the called terminal locates has no NAT devices.

4. The method according to claim 1, further comprising the step of: requesting a server to exchange role between the initiator and the called so as to make the called terminal initiate a call to the initiator terminal for communication operation, if judging that the network where the initiator terminal locates have no NAT devices whereas the network where the called terminal locates has NAT devices.

5. The method according to claim 1, further comprising the step of: requesting a server for relaying service to make the initiator terminal and called terminal perform the communication operation if judging that the networks where the initiator terminal and the called terminal respectively locate have NAT devices.

6. The method according to claim 3 or 4, further comprising the step of: requesting a server for relaying service to make the initiator terminal and called terminal perform the communication operation, if judging that the NAT devices do not support the communication operation.

7. The method according to any one of claims 2-4, further comprising the step of: requesting a server for relaying service to make the initiator terminal and called terminal perform the communication operation, if a direct communication between the initiator terminal and the called terminal fails.

8. The method according to claim 1, wherein the judge step includes requesting a server to judge whether the networks where the initiator terminal and the called terminal respectively locate have NAT devices or not.

9. The method according to any one of claims 4-8, wherein the server is an Instant Messaging server.

10. The method according to claim 1, wherein the communication operation is VoIP.

11. A terminal, including: judge means for judging whether networks where the initiator terminal and a called terminal respectively locate have NAT devices or not; and selection means for selecting the corresponding communication path for communication operation based on the judged result.

12. The terminal according to claim 11, further comprising: communication operation means, wherein the selection means controls the communication operation means to directly communicate with the called terminal, if judging that the networks where the initiator terminal and the called terminal respectively locate have no NAT devices.

13. The terminal according to claim 11, further comprising: communication operation means, wherein the selection means controls the communication operation means directly communicates with the called terminal, if judging the network where the initiator terminal locates has NAT devices whereas the network where the called terminal locates has no NAT devices.

14. The terminal according to claim 12 or 13, wherein the communication operation means is VoIP means.

15. The terminal according to claim 12 or 13, further comprising: relaying request means, wherein the selection means controls the relaying request means to request a server to exchange role between the initiator and the called so as to make the called terminal initiate a call to the initiator terminal for communication operation, if judging the network where the initiator terminal locates has no NAT devices whereas the network where the called terminal locates has NAT devices.

16. The terminal according to claim 12 or 13, further comprising: relaying request means, wherein the selection means controls the relaying request means to request a server for relaying service to make the initiator terminal and called terminal perform the communication operation, if judging that the networks where the initiator terminal and the called terminal respectively locate both have NAT devices.

17. The terminal according to claim 15, wherein the relaying request means is Instant Messaging means.

18. The terminal according to claim 16, wherein the relaying request means is Instant Messaging means.