METHOD AND APPARATUS FOR AVOIDING IP-ADDRESS COLLISION WHEN CONNECTING AN INCOMING VOICE PHONE CALL TO AN INTERNET APPLICATION

Abstract: The present invention discloses a method and an apparatus for solving the problem with how to avoid IP-address collision when connecting an incoming voice phone call to an internet application. The problem is solved by from time to time, for each entry in the list, sending a message to an applicated located on the IP-address and depending on the answer or the lack of an answer updating the list.

Description: METHOD AND APPARATUS FOR AVOIDING IP-ADDRESS COLLISION WHEN CONNECΗNG AN INCOMING VOICE PHONE CALL TO AN INTERNET APPLICATION TECHNICAL FIELD OF THE INVENTION The present invention relates to Internet and telecommunication in general and to maintaining an accurate association between A- numbers and IP-addresses in particular. DESCRIPTION OF RELATED ART A telephone user, hereafter called a subscriber, may, by using a modem, connect to an ISP (Internet Service Provider) and thus get access to the Internet through his regular voice telephone. The drawback is that while the subscriber is using his internet account (surfing) his phone is busy and therefore will anyone dialling to the subscriber get a busy-tone. This can be solved as described in the Swedish application SE-9602212-4 by forwarding calls to the subscriber to a voice gateway. The voice gateway handles the translation between voice and internet and the subscriber will receive a message indicating a waiting voice call and can connect to the calling party using state-of-the-art voice-over-internet technology. This way the subscriber may simultaneously be connected to internet and using his voice phone. The subscriber may also place an outgoing call through the voice gateway in a similar manner. For a deeper description of the above mentioned ideas please refer to SE-9602212-4. To be able to direct voice calls coming to the voice gateway to the right destination it is vital to maintain an accurate list of the relation between a-number and IP-addresses. This issue is not solved in the related art. SUMMARY OF THE INVENTION The present invention discloses a method and an apparatus for solving the problem with how to avoid IP-address collision when connection an incoming voice phone call to an internet application. The purpose of the present invention is to be able to avoid IP- address collision and to be able to maintain an accurate reference list with IP-addresses and phone numbers. The problem, described above, regarding how to avoid IP-address collision and to maintain an accurate IP-address and A-number list is solved by from time to time, for each entry in the list, send a message to an application located on the IP-address and depending on the answer or the lack of an answer update the list. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 shows in overview a logical network model. Figure 2 shows in more detail the phone-doubler and its interfaces. Figure 3 displays a physical network model. Figure 4 shows an overview of a preferred embodiment according to the invention. Figure 5 shows an flowchart of a preferred embodiment according to the invention. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS I the following description, for purposes of explanation and not limitation, specific details are set forth, in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practised in other embodiments that depart from these specific details. In other instances, detailed descriptions of well known methods, devices, and circuits are omitted so as not to obscure the description of the present invention with unnecessary detail. In figure 1 is a general overview of the surroundings of the network and how the phone-doubler interfaces with its neighbours. With 101 is a user -who is connected to the phone-doubler 102 denoted. The phone-doubler 102 is also connected to the ISP (Internet Service Provider) 103, to the ISDN (Integrated Services Digital Network) 104 and to ISP-adaptations 105. Such adaptations could for instance be a PCAU (PSTN Control Adaptation Unit) 106. The PCAU 106 is a unit that mediates between phone-doubler 102 and the network operators PSTN network, for the purpose of activation and deactivation of call diversions. Call diversion is an integral part of the workings of the phone-doubler. Another adaptation unit can be a CCAU (Customer Care Adaptation Unit) 107, which is a unit that mediates between phone-doubler 102 and the customer care system of the ISP. The last adaptation unit shown in figure 1 is the BCAU (Billing Centre Adaptation Unit) 108, which is a unit that mediates between phone-doubler 102 and the billing centre of the ISP. In figure 2 a more detailed description of the inner working of the phone-doubler and its interfaces is shown. The user 201 is still present and is utilising the phone-doubler 202 through an UI (User Interface) 203. The UI could for instance be a Microsoft Windows application giving the user a windows user interface for handling the phone-doubler services. The user is using a client software 204 which could be the just mentioned windows application handling the communication with the gateway 206 over a CLGI (Client Gateway Interface) 205. The gateway 206 is located on the ISP 209 premises. The gateway 206 can be located at different geographical locations. The gateway 206 comprises a gateway registry 207 which is common to all subscribers to the phone-doubler services, and at least one VGWM (Voice Gateway Module) 208. The VGWM 208 processes the call and speech transmissions and can handle several calls simultaneous. The ISP has for operation and maintenance a OMI (Operation and Maintenance Interface) 210 to the phone-doubler 202. An PRI (Primary Rate Interface) 211 connects the phone-doubler 202 with the ISDN 212. For communication between the phone-doubler 202 and the ISP- adaptations 213 a number of different interfaces are used. PCAI (PSTN Control Adaptation Interface) 214 for communication with PCAU 215, CCAI (Customer Care Adaptation Interface) 216 for communication with CCAU 217 and BCAI (Billing Centre Adaptation Interface) for communication with BCAU 218. The client 204 is running on a PC (Personal Computer) 301 in figure 3, located at the users premises 302 and connected to the ISP's POP (Point Of Presence) 303, at the ISP's premises 304 via a modem 305 and PSTN 306. The PC 301 is given an IP-address 307 by the ISP. This is normally done dynamically when connecting to the POP 303. The users normal telephone line 308 is used for connecting between the modem 305 and the PSTN 306. One or several VGWM 309 is connected to the ISP's IP network 310, typically on the same switched Ethernet as the POP but not necessarily. Each VGWM 309 has its own IP-address, and the registry 311 may have an IP-address of its own, or share the IP- address of one of the VGWM' s 309. Each VGWM 309 is connected to ISDN 312 via PRI. One registry node 311 can handle several VGWM 309. The registry node 311 can physically be remotely placed. An ISP can have one central registry node 311 and several distributed VGWM 309. The client 204 in figure 2 stores a number of different data items such as : Country code Area code (including trunk prefix) Telephone number (local number) Service preferences client IP address (volatile) Hostname of registry VGWM IP address (volatile) • ISDN number to VGWM cluster (this may be a group number) Reject incoming calls (volatile, settable from the GUI) The combination of country code, area code, and local number identifies each subscriber uniquely. The VGWM IP address attribute also represents the state of the client: A null address indicates that the client is signed-off from the phone-doubler service, any other address indicates that the client is signed-on. The registry 311 holds a subscriber record for each client, where each record comprises the following attributes: • telephone number (key, persistent, made up from country code, area code, and local number) • password (persistent, stored with a one-way function encryption) • client IP address (secondary key, volatile) • user id (persistent) • service preferences (persistent) • number of sign-on (persistent) • number of incoming calls (persistent) • number of outgoing calls (persistent) • first sign-on (persistent) • last sign-on (persistent) The client IP address attribute also represents the state of the subscriber record, a null IP address states that the client 204 is signed-off, any other address states that the client 204 is signed-on. When a user 201 is connected to the Internet, the IP address of the client 307 is entered into the subscriber record. Since both the telephone number and this IP address are keys, an PSTN-to-IP association between the telephone number and IP address is maintained in the subscriber record. Whenever an event occurs in the phone-doubler service relating to the registry, a record is created in the registry 311 and stored in the registry log. The registry log contains records of events, relating to the session that takes place between a sign-on and a sign-off. A registry log record is created when a subscriber record changes state to signed-off, or when a subscriber record is deleted. The registry log record comprises the following attributes : • Record id (sequence number) • Termination date (timestamp of session termination) • Client IP address • user id • User's telephone number • Sign-on date • Duration • Number of incoming calls • Number of outgoing calls • Termination code (indicating which normal event or exception that terminated the session) The phone-doubler can have one or several VGWM' s . Each of these VGWM' s holds a record of each call or call attempt made through that particular VGWM. The call record may comprise the following attributes: • Record id (per-VGWM sequence number) • Date and time (timestamp of the completed log record) • Client IP address and port • User's telephone number • Direction (incoming or outgoing) • VGWM IP address and port • VGWM ISDN number • B-number (same as user's telephone number for incoming call) • Call set-up date and time • Duration • Sent packages • Received packages • Answer state. Answered, rejected or not answered • Termination reason. User, client, ISDN or VGWM. In figure 4 a user is denoted with 401. The user 401 has been connected to the ISP' s POP 402 and been assigned an IP-address 409. The user has also, during his internet session, signed-on to the phone-doubler service and in a registry 403, a record 404, in a table 405 has been created comprising at least the users assigned IP-address 409 and the A-number of the telephone line 410 used by the user 401 to connect to the internet. For some reason the user 401 has been disconnected form the ISP in a non standard way, leaving the record 404 unchanged. Since the record 404 is used to determine if a user is signed-on or not, it is important to have the table 405 correctly reflecting the current situation. If the IP-address of an user 401 is non-null the user 401 is regarded as signed-on. Previously, if the user 401 would try to sign-on again, the registry 403 would look into the table 405, find that the A- number in the table 406 already has an IP-address 408 and therefore must already be signed-on. The registry 403 would then refuse the user 401 admittance to the phone-doubler service. This is not the case, however, any longer, with the present invention. An auto-control function 407, located to the registry 403, is responsible for finding, and deleting faulty records. This auto- control function 407 executes, without manual intervention, periodically. The period for execution of the auto-control function 407 is reasonably short, so that a user 401 do not have to wait too long to be able to sign-on again. However, the period must be longer than the PPP inactivity time-out parameter. The auto-control function 407 controls each record 404 in the registry 403. If the state of the user 401 is signed-on, that is, if the IP-address 408 is non-null the auto-control function 407 connects to the user 401 to check if it is alive. If the user 401 responds no further action is taken and the auto-control function 407 proceeds with the next record 404 in the table. If the user 401 is not alive the auto-control function 407 will break the association between the A-number 406 of the user 401 and the IP- address 408 by setting the IP-address 408 to null. The registry logging function will also be updated. If the user 401 is alive but its A-number 410 does not match the A-number attribute 406 in the subscriber record the auto-control function 407 will issue an alarm and force the user indicated by the subscriber record to sign-off. Figure 5 shows a flow chart of the auto-control function. With 501 is an loop starting from zero and going through all k records in the table 405 denoted. In 502 a test is performed to see if the IP-address of the current record is zero. If so the next record in the table is handled. If not a message is sent in block 503 to the IP-address of the current record and the auto-control function waits for a message. Depending on the design of the auto-control function it can either halt execution while waiting for answer or continue to send messages to a number of different IP-addresses and handling each answer as they come. In this embodiment, for ease of understanding the auto-control function waits for an answer. In block 504 the auto-control function receives an answer. In 505 an authentication check is performed to verify that the IP-address matches the A-number stored. If the verification is okay the next record in the table is handled. If on the other hand the message received indicates a mismatch between the IP-address and the A-number the IP-address of the current record is set to zero in block 506 The invention being thus described, it will be obvious that the same may be varied in many ways . Such variations are not to be regarded as a departure from the spirit and scope of the invention, and all such modifications as would be obvious to one skilled in the art are intended to be included within the scope of the following claims.

Claims: CLAIMS 1. A method for verifying records in a table, wherein each record comprises at least an IP-address, CHARACTERISED in that a first message is sent • to said IP-number, that said table is altered in dependence of the contents of a second message received from said IP-address or the lack of a second message. 2. A method according to claim 1, CHARACTERISED in that said IP- address is set to zero if no second message is received within a specific time. 3. A method according to claim 1, CHARACTERISED in that said second message comprises a first A-number, that said records in said table comprises an second A-number and that the said IP-address is set to zero and an alarm is issued if the first and second A-numbers do not match. 4. A method according to claim 1, CHARACTERISED in that said verification is performed repeatedly for each record with a specific time interval. 5. An apparatus for verifying records in a table, wherein each record comprises at least an IP-address, CHARACTERISED in means for sending a first message is to said IP-number, means for receiving a second message from said IP-address, means for altering said table in dependence of the contents of said second message or the lack of reception of said second message. 6. An apparatus according to claim 1, CHARACTERISED in means for setting said IP-address to zero if no second message is received within a specific time. . An apparatus according to claim 1, CHARACTERISED in that said second message comprises a first A-number, that said records in said table comprises an second A-number and means for setting said IP-address to zero and issue an alarm if the first and second A-numbers do not match. 8. An apparatus according to claim 1, CHARACTERISED in means for performing said verification repeatedly for each record with a specific time interval.

Inventors: FOGELHOLM RABBE, SVEDBERG JOHAN, FOGELHOLM, RABBE, SVEDBERG, JOHAN
Applicants: ERICSSON TELEFON AB L M, FOGELHOLM RABBE, SVEDBERG JOHAN, FOGELHOLM, RABBE, SVEDBERG, JOHAN, TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
Application year: 1997
Main classification: G06F11
IPC codes: H04M3, H04M7, H04M15