Location information for remote user

[0001] The present invention relates to a method to set up an Internet Protocol session from a remote terminal via a remote access server using a telephone network being able to send calling line identity information. Furthermore, it is related to a computer readable medium having a computer program recorded thereon, the computer program comprising codes adapted to perform steps of said method to set up an Internet Protocol session when said computer program is run on a computer possibly being said remote access server. It is also related to a computer readable medium having a computer program recorded thereon, the computer program comprising codes adapted to perform steps of said method to set up an Internet Protocol session when said computer program is run on a remote terminal. The invention is based on the priority applications EP 03 025 153.2, EP 03 027 831.1 which are hereby incorporated by reference.

[0002] A recent societal trend calls for more employees to work from home or other sites that are remote from the corporate office. This is achieved via remote access to data networks.

[0003] The traditional way remote employees accessed the corporate network is via Long Distance dial to a remote access server in the corporate data center. Such remote access server or local call server is a device that answers incoming phone calls with racks of modems, authenticates users as authorized data users (not hackers) and hands data queries to the corporate network. Dozens or even hundreds of remote users or workers may almost simultaneously dial in to dozens or hundreds of modems, in one remote access server.

[0004] Internet Service Providers are now setting up Internet Protocol IP access in remote access server nodes all over the world. The IP network can give them a great way to provide access to remote users.

[0005] The traditional approach takes bursty data traffic and it carries it on Constant Bit Rate telephone calls circuits for such a long distance—usually all the way to corporate headquarters. This explains why they are quite expensive. And the bursty traffic inefficiently uses the circuit bandwidth, because there are often long periods of silence. In contrary, the Internet Service Provider ISP remote access service can be more efficient because ISP carries the data call on a circuit for only a short distance—the local phone call distance between the remote user and a remote access server in a local office. The remote access server will terminate the circuits of multiple users, multiplex the bursty data efficiently into one packet stream, and conserve long distance circuits. This last service for support of remote and mobile employees is often named Dial Internet Protocol, Virtual Private Dial Networking, or simply remote access.

[0006] An example of a software supporting such remote access is given by the product called Windows NT 4.0 Remote Access from Microsoft. With Windows NT remote access, remote access clients connect to remote access servers and are transparently connected to the remote access server, known as point-to-point remote access connectivity. Alternately, they are transparently connected to the network to which the remote access server is attached, known as point-to-LAN remote access connectivity. This transparent connection allows remote access clients to dial-in from remote locations and access resources as if they were physically attached to the network.

[0007] That software product provides two different types of remote access connectivity:

[0008] (i) Dial-up remote access, where a remote access client uses via the telecommunications infrastructure to create a temporary physical circuit or a virtual circuit to a port on a remote access server. Once the physical or virtual circuit is created, the rest of the connection parameters can be negotiated.

[0009] (ii) Virtual private network remote access where a client uses an IP network to create a virtual point-to-point connection with a remote access server acting as the virtual private network server. Once the virtual point-to-point connection is created, the rest of the connection parameters can be negotiated.

[0010] Nowadays, voice-over-IP (VOIP) starts to be of enough good quality that enterprise customers move to implement Voice-over-IP networks. It is directly related to the hope to decrease the costs associated with maintaining multiple networks and increase productivity as new applications are brought to market extending the application of voice communication. Voice-over-IP enables carrying voice traffic (for example, telephone calls and faxes) over an IP network. This support is implemented using voice packet technology. In voice-over-IP, the digital signal processor segments the voice signal into frames and stores them in voice packets. These voice packets are transported using IP in compliance with one or several signaling specifications. But when an enterprise network provides IP telephony service, it must be able to support so called Emergency Calling Service ECS also known in the US and Canada as E911. Indeed the enterprise network must have the capability of determining the user's location and call back number, routing the call to the appropriate Public Safety Answering Point PSAP, and conveying the location and call back information to that PSAP.

[0011] For an enterprise IP network to properly support ECS, it must achieve the following:

• • [0012] Identify the location of ECS user and dispatch help to the correct location within a limited time;
  • [0013] Connect the ECS call to the appropriate PSAP jurisdiction. The correct PSAP is usually the one nearest the user;
  • [0014] Location information provide correct emergency location information number of the ECS user so that the PSAP can dispatch help to the correct location;
  • [0015] Call back information provide the correct number for calling back the ECS user in case the call is disconnected.

[0016] The key to supporting the first three requirements is enterprise network determination of the user's location, regardless of the terminal access scenario.

[0017] In view of the above, it is an object of the present invention to provide a method and some computer program codes adapted for identifying the location of a remote user setting up an Internet Protocol session from a remote terminal to a remote access server.

[0018] This object starts to be of an issue when an user that has a telephony device installed, e.g. in a laptop computer, or other portable device, uses that device from a remote location to call an emergency calling service ECS when connected to the enterprise network. This is possible by applying a method in accordance with the invention to set up an Internet Protocol session from a remote terminal via a remote access server using a telephone network. It is required that the telephone network is able to send calling line identity information of said remote terminal when setting up a telecommunication. This is usually the case for telephone network based on integrated services digital network ISDN. At first, the remote user will set up a telecommunication from said remote terminal to said remote access server through the telephone network. Consequently, the telephone network will provide calling line identity information of said remote terminal to said remote access server while this first telecommunications being identified by said remote access server as being performed by a remote worker. The remote access server will then answer or acknowledge said telecommunications by rejecting it with some tag (e.g. reason for reject information element) to be forwarded to said telephone network. Said tag can comprise a specific label with some information of the reason for rejection. More or less in the same time, the remote access server will register the received calling line identity information to which it will associate said forwarded tag. The remote terminal will receive a disconnection message with said tag forwarded from said telephone network. Said further telecommunications will then be definitively disconnected. But advantageously, the remote terminal will possibly automatically initiate an Internet protocol session to said remote access server using said tag possibly but not exclusively together with some login procedure. When said remote terminal will be interconnected with the remote access server through said Internet Protocol session, then the remote access server will identify said remote terminal. The identification procedure will be based on the use of the registered calling line identity affected to said tag.

[0019] Once a remote user achieve to set up an Internet Protocol session from a remote terminal according to the invention, he will be in the situation to use that Internet Protocol session for the setup of a voice over Internet Protocol telecommunication VoIP. In such a way, he will be able to perform a VoIP telecommunications from his remote terminal to some user connected to the remote access server or even someone outside the enterprise network if such a remote access server would allow such service. The present invention provides the big advantage that when the remote user will use such VoIP telecommunications for an emergency call ECS, the remote access server will be able to forward user location from said remote terminal possibly but not exclusively to some public safety answering point. This user location will be extracted from the registered calling line identity corresponding to said remote terminal.

[0020] The invention also relates to computer readable medium having a computer program recorded thereon, the computer program comprising codes adapted to perform some steps of the above method to setup an Internet Protocol session. One of the computer program is running on a computer possibly being the remote access server which will at first accept the set up of a first telecommunications with some remote user through a telephone network being able to send calling line identity information. Said first telecommunications will be identified by the remote access server as being performed by a remote user. The remote access server will then register the corresponding calling line identity information from the remote terminal and forward a tag when rejecting the first telecommunications from said remote terminal. It is possibly this tag which will initiate on said remote terminal an Internet Protocol session after disconnection of the first telecommunications. At least, the tag will have to be forwarded when setting up the Internet Protocol session from the remote terminal to the remote access server. And then some codes of the computer program will be used to find out the registered calling line identity information affected to the received tag. Only then, the remote access server will be able to identify the remote terminal interconnected with it through said Internet Protocol session.

[0021] A second computer program is running on the remote terminal from where the remote user may initiate its call. That second program is adapted for setting up a first telecommunications to the remote access server through a telephone network providing calling line identity information of said remote terminal. Said first telecommunications will be specified by the remote terminal as being performed by a remote user. When the remote terminal will receive some tag forwarded from said remote access server, it will disconnect said telecommunications. And then, it will initiate an IP session to said remote access server using said tag. All these steps on the remote terminal may be launched possibly only after the remote user performed successfully some user access procedure like a login procedure.

[0022] Advantageous developments of the invention are described in the dependent claims, the following description and the drawings.

[0026] The present invention consists in synchronizing the enterprise server (remote access server) before a voice-over-IP call setup will be initiated by some user at a remote location i.e. outside the enterprise premise. At first an ISDN call setup will be initiated by a remote user on a remote terminal and established between the gateway at the remote location and the remote access server. This first telecommunications must be identified by the remote access server as being performed by some remote user. This may be achieved through different ways. A possibility could be by dialing a specific telephone number for setting up said first telecommunications, while said specific telephone number being associated to said remote access server and dedicated to remote users. An alternative could be given by transmitting to said remote access server some remote user indication together with the calling line identity information to be used by said remote access server for the identification of the first telecommunications as being performed by a remote user. Such remote user indication could be transmitted using e.g. User to User Messaging, some service supported by ISDN. This remote user indication could be set in a transparent way for the remote user e.g. by some software possibly on the remote terminal. The remote user would then have to perform successfully some user access procedure like a login prior to set up the first telecommunications.

[0027] When the first telecommunications will be identified by the remote access server as being performed by a remote user, it will initiate some steps on the remote access server specific for a remote user. At first, it will answer this first call by rejecting it and avoid extra costs while the call reference and CLI are stored for future synchronization. When rejecting it, the remote access server will use some tag to be forwarded to said remote terminal. The network will then forward a disconnection message together with this tag to the remote terminal.

[0028] After the reception of such specific tag, the remote terminal will activate the establishment of a session according to e.g. RTP (Real-time Transport Protocol) while the previously sent tag will be used as a synchronization word to establish the link between that specific session and the ISDN phone number from which it was set up. It is the reception of that tag by the remote access server when establishing the session that will make it possible to get location information in case of emergency call later on.

[0029] On FIG. 1a is shown a remote terminal connected to a telephone network (1) here as ISDN. According to the invention, it is required, that the telephone network is able to send calling line identity information from that remote terminal as it is the case for an ISDN network. To that ISDN network is connected some internet service provider ISP via a connection (2) which is itself connected (4) to the Internet. Also is connected to the ISDN network a remote access server of an enterprise via connection (3). Such remote access server is itself connected (6) to some Intranet, typically a network accessible only for a restricted number of users usually the employees of that enterprise. The Intranet is also connected to the Internet (5) while usually between both is placed at least a firewall not shown on that figure.

[0030] On FIG. 1b is shown different steps according to the invention and following FIG. 1a. At first, a set up of a telecommunication from said remote terminal to the remote access server is initiated by the user at its remote location. It can be of advantage to authorize such set up only after performing successfully some user access procedure like a login usually on the remote terminal. That set up follows usual standard Q.931 adapted for telephone network able to send calling line identity information CLI of that remote location, together with some remote user (rw) indication to the remote access server. This remote user (rw) indication transmitted possibly using User to User signaling, will be used by the remote access server to identify that call as being performed by a remote user. In such a way, it can differentiate the specific call performed by remote users from the “usual” call for which no specific procedure must be applied. The remote access server will then answer such telecommunications coming from a remote user by rejecting it while such rejection being characterized with some tag (SYN#). Possibly at the same time, the remote access server will register the received calling line identity information from that remote location together with the tag sent. Such rejection of the first telecommunications will be forwarded together with the tag (e.g. together with login password) by the telephone network to the remote terminal. The reception of a characteristic disconnection message according to Q.931 will definitely disconnect said telecommunications while the remote terminal will keep track of the received tag. This tag will be used in the following initiation of an Internet protocol session from the remote terminal to the remote access server. Such IP session set up may be based on any protocol stack (HTTP, SIP, H.323). The tag SYN# parameter is the reference that is to be used at IP Session set up to be able to make the relationship between this particular session and the corresponding calling line identity information CLI. It might also be directly the CLI value, making it possible to handle location of the remote terminal.

[0031] Such an IP session can be advantageously used for a VoIP telecommunications particularly for an emergency call. The set up of the Internet protocol session can be performed via an Internet Service Provider ISP. Through such ISP using connection 4, 5, 6 (see FIG. 1a and FIG. 1b) it will also be possible to access to the remote access server. It might be preferable in that case to have to perform some login procedure to be allowed to access the Intranet i.e. to be let in by the Firewall. Alternately, it is possible to reach the remote access server by dialing a specific telephone number for setting up said first telecommunications. Such specific telephone number being associated to the remote access server will be dedicated for the set up of an Internet Protocol session according to the invention.

[0032] Once some user at a remote location performed an emergency call as VoIP via an IP session according to the invention with the remote access server, that remote access server will know the remote location. It will then have to determine the right emergency service zone and corresponding number. This can be done as usual, manually at location information server configuration, or through dialogue between the remote access server and the public location information server database.