JP4093008B2 - Network telephone system and program - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a network telephone system and a program including a plurality of telephone terminals for packet-converting input voice information and transmitting it on a network.
[0002]
[Prior art]
In recent years, VoIP terminals (Internet telephone terminals) that convert input voice information into packets and transmit them to the Internet have begun to spread. Conventionally, however, the VoIP terminals that are connected to the Internet dynamically There is known an Internet telephone system that supports DHCP (Dynamic Host Configuration Protocol) for assigning an IP (Internet Protocol) address (see Patent Document 1).
[0003]
[Patent Document 1]
JP 2001-203806 A
[0004]
By the way, in the case of a notebook type or mobile type VoIP terminal that can be arbitrarily moved to any one of a plurality of subnets (local nets) divided into groups in the system, it is usually installed. Since there is a case of moving from a location subnet to another location subnet, the location information of the terminal is managed.
In this case, as defined in RFC (Request for Comments) 2543, the management of the address of the VoIP terminal and the location information of the location where the VoIP terminal is connected is performed by a SIP (Session Initiation Protocol: Session) that is a VoIP server. Starting protocol) is done by the server.
[0005]
FIG. 19 is a diagram for schematically explaining a general SIP server.
The SIP server 100 is arranged for each subnet in which the system is grouped, and has a configuration having a register function, a proxy function, and a redirect function, which will be described later.
In the figure, (1) to (7) are operation procedures showing the flow of operation, (1) and (2) (registration) are executed asynchronously, and (3) (calling) It is completed before execution, and subsequent operations (3) (call), (4) (inquiry), (5) (call), (6), and (7) (response) are continuously executed. It is shown that.
[0006]
When the register function in the SIP server 100 accepts a registration request transmitted from each VoIP terminal 101, 102, the correspondence function between the virtual SIP address and the actual SIP address is given to the location server 103 for each terminal. It is a function for registering. Note that the virtual SIP address and the real SIP address are addresses assigned to each terminal in consideration of the possibility that each of the VoIP terminals 101 and 102 may move, and the actual destination address is the real SIP address. Indicated by the address.
[0007]
In this state, when the caller terminal 101 makes a call by designating the virtual SIP address of the call partner, the proxy function in the SIP server 100 makes an inquiry to the location server 103 and makes a call. This is a function for acquiring a real SIP address associated with the virtual SIP address of the other party, making a call to the terminal 102 on the incoming side, and returning a response to the terminal 101 on the outgoing side.
In this case, the redirect function in the SIP server 100 is such that when the terminal 102 on the receiving side moves to another subnet managed by another SIP server 100, The real SIP address is returned. Note that LDAP (Lightweight Directory Access Protocol) is interposed between the SIP server 100 and the location server 103.
[0008]
[Problems to be solved by the invention]
However, as described above, the address and location information of each VoIP terminal 101, 102 is managed by the SIP server 100 provided for each subnet. However, introducing an expensive SIP server 100 There were problems such as high initial introduction costs and increased operational costs.
[0009]
An object of the present invention is to call a call partner using a telephone terminal that converts voice information into packets and transmits it over a network. Protocol: Session initiation protocol) A network telephone system that can be called by utilizing a telephone directory function provided on each telephone terminal side without introducing a server.
[0010]
[Means for Solving the Problems]
The invention according to claim 1 is a network telephone system comprising a plurality of telephone terminals for packet-converting input voice information and transmitting it on the network, wherein the telephone terminal is a currently used user. User name storage means for temporarily storing names, and all network addresses assigned to each telephone terminal corresponding to a plurality of subnets are stored and managed as telephone directory data for each destination, and the user names are also matched. Phone book storage means for storing and managing, and when a call partner is selected and specified from the phone book, all network addresses are sequentially read from the phone book data associated with the call partner And an address reading means for reading the user name registered in the telephone directory, and the address reading means Calling means for connecting the user name to each network address and calling the telephone terminal of the other party, and when there is an incoming call from the calling telephone terminal, it is temporarily stored in the user name saving means Comparing the user name currently in use with the user name sent from the calling telephone terminal combined with the network address, and if the two are different, there is provided an incoming means for performing an error response. It is characterized by.
Furthermore, a program for causing a computer to function as the main means shown in the above-described invention according to claim 1 is provided (the invention according to claim 2).
[0017]
DETAILED DESCRIPTION OF THE INVENTION
(First embodiment)
A first embodiment of the present invention will be described below with reference to FIGS.
FIG. 1 is a block diagram showing the overall configuration of the network telephone system in this embodiment.
This network telephone system is a wireless LAN system, and is divided into a plurality of (in this embodiment, two) subnets (local nets) (1) and (2) as a whole, and a plurality of VoIP terminals. 1, the VoIP terminals “A” and “B” are connected to the subnet {circle around (1)} side, and the VoIP terminals “C” and “D” are connected to the subnet {circle around (2)} side. In order to simplify the description, FIG. 1 illustrates a case where the number of subnets is “2” and the number of VoIP terminals 1 is “4”.
[0018]
Each VoIP terminal 1 is a notebook-type or mobile-type personal computer that has Internet telephone software installed therein, converts voice information into packets and transmits it over the Internet, and uses the standard TCP / IP protocol of the Internet. Since the call partner is called, the IP address of the call partner is input and designated at the time of calling. In this embodiment, the Internet is described as an example of the network. However, the network form is not limited to the Internet, and it is needless to say that the network can be widely applied to other network systems.
A DHCP (Dynamic Host Configuration Protocol) server 2 dynamically assigns an IP address to each VoIP terminal 1, and in this embodiment, a single DHCP server 2 is used. Thus, an IP address is assigned to the VoIP terminal 1 on each of the subnets (1) and (2). The DHCP server 2 is connected to a router 3 that performs a relay operation, and is connected to each VoIP terminal 1 via a wireless LAN including an access point 4.
[0019]
FIG. 2 is a diagram showing the relationship between the connection location of each VoIP terminal 1 managed on the DHCP server 2 side and the IP address assigned to each terminal corresponding to that location. In this case, on the DHCP server 2 side, for each VoIP terminal 1, in addition to its MAC address (hardware address), an IP address assigned to each VoIP terminal 1 corresponding to the subnets (1) and (2) is stored. to manage. That is, in this embodiment, each VoIP terminal 1 stores and manages its IP address corresponding to all subnets. Of the data constituting the IP address, in the figure, “128.1.1” indicates the address of subnet (1), “128.1.2” indicates the address of subnet (2), Further, “100” to “103” subsequent to the subnet address indicate addresses of the corresponding VoIP terminals “A” to “D”.
[0020]
FIG. 3 is a diagram showing the configuration of the telephone directory file 10 managed on each VoIP terminal 1 side.
The telephone directory file 10 provided corresponding to each VoIP terminal 1 has an IP address “1” that is associated with all subnets for each recipient name (destination name) “A” to “X”. To “n”. In other words, as many IP addresses as the number of subnets are stored, and in the above example, there are two types of IP addresses corresponding to the subnets (1) and (2), according to the names of the recipients A to D. An IP address is stored as telephone directory data. In the first embodiment, the plurality of IP addresses associated with individual callee names are arranged in the order of subnets (1) and (2).
The phone book file 10 configured in this way is created by one of the VoIP terminals 1, and when the VoIP terminal 1 of the creation source delivers the phone book data to all other VoIP terminals 1. Each of the other VoIP terminals 1 receives and acquires the phone book data and registers it in its own phone book file 10.
[0021]
Each VoIP terminal 1 reads the contents of its own phone book file 10 and displays a list of the names of the other parties when starting a call by designating a desired VoIP terminal 1. In this state, when a desired destination is selected and designated as a call destination from the destination name list screen, the VoIP terminal 1 accesses the phone book file 10 and makes a call associated with the call destination. A book record is designated as a reading target, all IP addresses stored in the designated record are sequentially read out one by one, and the VoIP terminal 1 that is a call partner is sequentially called. As a result, all the VoIP terminals 1 on the subnets {1}, {2} side are called by the respective IP addresses.
[0022]
FIG. 4 is a block diagram showing basic components of the VoIP terminal 1.
The CPU 11 is a central processing unit that controls the overall operation of the VoIP terminal 1 according to the operating system and various application software in the storage device 12. The storage device 12 has a program storage area and a data storage area. In the program storage area, various application programs and the like are stored in addition to the operating system. A book file 10 and the like are stored, and are constituted by a magnetic, optical, semiconductor memory, and the like and a drive system thereof.
[0023]
The recording device 12 may have a configuration in which a removable storage medium such as a CD-ROM or DVD can be mounted in addition to a fixed memory such as a hard disk. The programs and data in the storage device 12 are loaded into a RAM (for example, static RAM) 13 as needed, or the data in the RAM 13 is saved in the storage device 12. The RAM 13 has a program execution area and a work area.
Further, the CPU 11 can directly access and use programs / data on the other electronic device side via the wireless LAN device 14 or can receive and download via the wireless LAN device 14. On the other hand, an input device 15, a display device 16, a microphone 17, and a speaker 18 which are input / output peripheral devices are connected to the CPU 11 via a bus line, and the CPU 11 controls their operations according to an input / output program. .
[0024]
Next, the operation algorithm of the network telephone system in the first embodiment will be described with reference to the flowcharts shown in FIGS. Here, each function described in these flowcharts is stored in the form of a readable program code, and operations according to the program code are sequentially executed. It is also possible to sequentially execute operations according to the program code transmitted via the transmission medium. The same applies to other embodiments to be described later. In addition to a recording medium, an operation peculiar to this embodiment can be executed using a program / data supplied externally via a transmission medium.
[0025]
FIG. 5 is a flowchart showing telephone directory data creation / registration processing executed by the VoIP terminal 1 side.
First, when the menu item “New creation / edit” is selected and designated from the work menu screen (step A1), the VoIP terminal 1 displays a phone book creation / edit screen and the phone book in this screen. When data is input, phone book data is created / edited based on the input data (step A2). Here, when the end of creation / editing is instructed, this phone book data is newly saved / overwritten in its own phone book file 10 (step A3).
[0026]
Here, in the VoIP terminal 1 which is the creation / editing source of the phone book data, when the “Send” menu item is selected and designated from the work menu screen (step A1), the phone book file 10 is read out and this phone call is read out. The book file 10 is sent as an email attachment to all other VoIP terminals 1 (step A4). Now, all the other VoIP terminals 1 that have received the mail from the VoIP terminal 1 that is the creation / editing source of the telephone book data (step A5) receive and acquire the attached file (phone book data) from the mail (step A6). ) Newly saved / overwritten in its own phone book file 10 (step A3).
[0027]
FIG. 6 is a flowchart showing a call calling process (dial process) executed by each VoIP terminal 1 side.
First, the VoIP terminal 1 accesses its own telephone directory file 10 to read each called party name (destination name) and display a list screen of the called party name (step B1). When a desired communication partner is selected from the partner list screen (step B2), a telephone directory record corresponding to the selected partner is specified as a reading target (step B3). In this state, one of the IP addresses in the designated record is read according to the arrangement order (step B4), and a call is made to this IP address according to RFC (Request for Comments) 3261 (step B5). If there is no response from the other party even after a predetermined time has elapsed since the call was made (YES in step B6), it is determined that a time-out has occurred, and the process proceeds to step B7, and all IP addresses are selected from the telephone book record corresponding to the selected party. It is determined whether or not it has been acquired.
[0028]
Since it is a case where the first IP address (subnet (1) compatible address) is acquired, the process returns to step B4, and the next IP address (subnet (2) compatible address) is acquired from the telephone book record corresponding to the selected partner. Thereafter, the above calling operation is repeated (steps B4 to B7).
As a result, even if all the IP addresses are acquired and the calling operation is performed, if there is no response from the other party (YES in step B7), the dialing process is terminated as a calling error. If there is a response from (NO in step B6), it is determined that the dial processing has been completed normally and the process ends.
[0029]
As described above, in the first embodiment, all the IP addresses assigned to each VoIP terminal 1 corresponding to a plurality of subnets are stored and managed in the telephone directory file 10 for each destination. When the call partner is selected and specified from the phone book file 10, the calling VoIP terminal 1 sequentially reads all IP addresses from the phone book record associated with the call partner. Since the call is made, no matter what location (subnet) the call partner moves to, all the terminal calls can be made for each subnet on the system, and the call partner can be called reliably. It becomes possible. Therefore, since it can be realized by a simple method of utilizing the telephone directory function provided on the telephone terminal side without introducing a conventional SIP server, the entire system is greatly simplified, and the initial introduction It is possible to provide a network telephone system having a high practical effect, such as reduction in cost and operation cost.
[0030]
Further, when the phone book data newly created / edited by any VoIP terminal 1 among a plurality of VoIP terminals 1 is distributed to all other VoIP terminals 1, each VoIP terminal 1 transmits the phone book data. Since it is received and registered in its own phone book file 10, it is no longer necessary to individually create / edit the phone book file 10 having the same contents, and the entire system can efficiently create / edit phone book data. It is possible to perform well.
[0031]
In the above-described first embodiment, the case where two subnets (1) and (2) are constructed on the system is illustrated, but of course, the number of subnets is arbitrary, and three or more subnets are constructed. Also good. In this case, as described above, IP addresses corresponding to the number of subnets may be stored and managed in the telephone directory file for each destination.
In addition to providing the DHCP server 2 commonly used for a plurality of subnets, the DHCP server 2 may be provided for each subnet.
[0032]
(Second Embodiment)
The second embodiment of the present invention will be described below with reference to FIGS. In the first embodiment described above, all the IP addresses associated with the call partner are sequentially read out from the phone book record one by one according to the arrangement order, and the VoIP terminal 1 of the call partner is called. However, in the second embodiment, all the IP addresses are sequentially read out one by one from the phone book record in accordance with the preset priority order, and the call destination VoIP terminal 1 is called. It is a thing.
Here, components that are basically the same in both embodiments are denoted by the same reference numerals, description thereof will be omitted, and the following description will focus on the features of the second embodiment.
[0033]
FIG. 7 is a diagram showing the structure of the phone book file 10 in the second embodiment.
As in the first embodiment described above, the telephone directory file 10 stores IP addresses “1” to “n” associated with all subnets for each of the recipient names “A” to “X”. In addition, the second embodiment is configured to store “priority” indicating the reading order corresponding to each IP address for each callee name.
In this case, when newly creating / editing phone book data, a new input field for inputting the priority order is provided on the creation / editing screen. For example, the place where the user normally works is given the highest priority, and then given the next priority. The priority is entered in the input field corresponding to each IP address so that the place is likely to move.
[0034]
FIG. 8 is a flowchart showing call call processing (dial processing) executed by each VoIP terminal 1 side in the second embodiment.
First, in a state where the VoIP terminal 1 has accessed the telephone directory file 10 and displayed a destination name list screen (step C1), a desired call destination is selected and designated from the destination list screen. If so (step C1), the telephone directory record corresponding to the selected party is designated as a reading target (step C3). Then, with reference to the “priority order” associated with each IP address in the designated record, the reading order is determined (step C4).
Thereafter, each IP address is read one by one in accordance with the reading order indicated by the “priority order” (step C5), and the same calling operation as in the first embodiment is repeated (steps C5 to C8).
[0035]
As described above, in the second embodiment, since it is possible to arbitrarily set the priority order for sequentially reading out each IP address associated with the call partner, for example, the place where you normally work is If priority is set corresponding to each IP address, such as setting the highest priority and the place where there is a high possibility of moving on a daily basis as the next priority place, one IP address is assigned according to the order. It can be read out one by one, and it is possible to quickly call the other party.
[0036]
In the second embodiment described above, when “priority order” indicating the reading order of each IP address is set, “priority order” is displayed in the creation / editing screen when newly creating / editing phone book data. However, it is also possible to automatically set the “priority order”.
9 and 10 exemplify the case where the priority order is automatically set, and FIG. 9 is a diagram showing a schedule file SF for managing each person's action schedule.
The schedule file SF is stored and managed on the side of a schedule server (not shown), and stores location information (subnet) indicating where each time zone corresponds to each VoIP terminal 1. It has become. For example, the VoIP terminal “A” is in a place where he / she usually works (subnet (1)) between “9:00 and 15:00”, but “after 15:00” It shows moving to the subnet (2)).
[0037]
FIG. 10 is a flowchart showing the operation of the VoIP terminal 1 when the priority order is automatically set with reference to the schedule file SF.
First, the VoIP terminal 1 accesses the system date and time to acquire the current time (step D1) and acquires the schedule file SF (step D2). Then, the schedule file SF is accessed based on the current time, the location information of the time zone corresponding to the current time is read, and the priority of the IP address associated with the location is set as the highest priority (step D3). . Now, in the VoIP terminal “A”, if the current time is “11:30”, it corresponds to the time zone “9:00 to 15:00” and corresponds to the place where he / she usually works (subnet (1)). The priority order of IP addresses is set as the highest priority. Then, with the current time as a reference, the priorities of IP addresses corresponding to other time zones are sequentially set according to the progress of time (step D4). In this case, in the VoIP terminal “A”, the next time zone “after 15:00” is set as the next highest priority for the IP address corresponding to the subnet (2).
[0038]
If the priority order is automatically set with reference to the schedule file SF in this way, it is not necessary to set the priority order manually, and it is not necessary to know the actions of the other party in advance. The efficiency of the entire system can be increased.
Although the schedule server (not shown) is used as the management location of the schedule file SF, of course, the VoIP terminal 1 may store and manage the schedule file SF.
[0039]
(Third embodiment)
Hereinafter, a third embodiment of the present invention will be described with reference to FIGS. The first embodiment described above shows the case where the VoIP terminal 1 is applied to the subnets (1) and (2) where the VoIP terminal 1 may move. In the third embodiment, the VoIP terminal 1 may move normally. In order to be able to cope with the case where the VoIP terminal 1 moves to another location (subnet 3), access to the subnet 3 is via a SIP (Session Initiation Protocol) server. This is what I did.
Here, basically the same components in both embodiments are denoted by the same reference numerals, and the description thereof is omitted.
[0040]
FIG. 11 is a block diagram showing a network telephone system in the third embodiment.
This network telephone system includes VoIP terminals “A” and “B” on the subnet {circle around (1)} side, VoIP terminals “C” and “D” on the subnet {circle around (2)} side, and VoIP on the subnet {circle around (3)} side. Terminals “E” and “F” are provided. The DHCP server 2 is connected to the router 3 and is connected to each VoIP terminal 1 via a wireless LAN including the access point 4. The SIP server 5 is connected to the VoIP terminals “E” and “F” on the subnet (3) side via the router 3 and the wireless LAN. Note that the DHCP server 2 and the SIP server 5 may be configured by a single server device having a DHCP server function and a SIP server function.
[0041]
FIG. 12 is a diagram showing the structure of the telephone directory file 10 in the third embodiment.
Similar to the first embodiment described above, this telephone directory file 10 stores two types of IP addresses corresponding to the subnets {1} and {2} for each recipient name. In particular, in this third embodiment, In order to make a call via the SIP server 5, the “SIP address” is additionally stored.
[0042]
FIG. 13 is a flowchart showing registration processing when the VoIP terminal 1 performs address registration with the SIP server 5 side.
First, the VoIP terminal 1 obtains a subnet address from its own IP address (step E1), accesses the telephone directory based on this address, and compares it with the place where it is usually located (step E2). That is, based on whether or not the subnet address acquired from its own IP address is registered in the telephone directory file 10, it is determined whether or not the place where the user is usually located. If the subnet address is registered in the phone book file 10, it is determined that the user is usually present and the registration process ends. If the subnet address is not registered in the phone book file 10, It is determined that the place is not present, and the process proceeds to step E3, where address registration is performed on the SIP server 5 side in accordance with RFC3261 / 3263.
[0043]
FIG. 14 is a flowchart showing call call processing (dial processing) executed by each VoIP terminal 1 side in the third embodiment.
First, when the VoIP terminal 1 accesses its own phone book file 10 and displays the destination name list screen, when a desired call destination is selected from the destination list screen (step) F1), a telephone directory record corresponding to the selected party is designated as a reading target (step F2). Then, as in the second embodiment described above, the “priority order” associated with each IP address in the designated record is referred to and the reading order is determined (step F3).
[0044]
Thereafter, each IP address is read one by one in accordance with the reading order indicated by the “priority order”, and the same calling operation as in the first embodiment is repeated (steps F4 to F7). As a result, if there is a response from any destination (NO in step F6), the dial processing is terminated normally, but the process ends. However, if no response is received from any destination (YES in steps F6 and F7). The process proceeds to the next step F8, where the “SIP address” is acquired from the telephone directory record corresponding to the selected party, and then a call is made via the SIP server 5 in accordance with RFC3261 (step F9).
[0045]
As described above, in the third embodiment, the VoIP terminal 1 registers an address with the SIP server 5 only when moving to a place where it does not normally exist (subnet (3)), and the other VoIP terminal 1 When calling the VoIP terminal 1 that has moved to the subnet {circle over (3)}, as in the first embodiment described above, each IP address associated with the other party is sequentially read from the phone book data and a call is made. If the call partner is not found, the call is made via the SIP server 5, so that the call partner can be called even if the call partner moves to a place where it does not normally exist. It is possible to increase the flexibility of the entire system.
[0046]
In the fourth embodiment described above, it is determined whether or not the user is usually present based on whether or not the subnet address acquired from the own IP address is registered in the telephone directory. As another determination method, an access point that is currently used may be identified, and based on this access point, it may be compared with an access point that is usually used by the user.
[0047]
(Fourth embodiment)
Hereinafter, a fourth embodiment of the present invention will be described with reference to FIGS. In the first to third embodiments described above, it is assumed that one user uses the VoIP terminal 1 exclusively, but in this fourth embodiment, one VoIP terminal 1 is shared by a plurality of users. It is applied when doing.
Here, basically the same components in both embodiments are denoted by the same reference numerals, and the description thereof is omitted.
[0048]
FIG. 15 is a diagram showing the structure of the phone book file 10 in the fourth embodiment.
This telephone directory file 10 stores IP addresses corresponding to each subnet for each recipient name, as in the first embodiment described above. In particular, in this fourth embodiment, for each recipient name. The “SIP user name” is additionally stored. In this example, the recipients “B” and “C” share the same VoIP terminal 1, and the IP addresses associated with the recipients “B” and “C” have the same contents. It has become.
[0049]
FIG. 16 is a diagram for explaining the outline of the operation of the fourth embodiment.
First, each VoIP terminal 1 performs a login process for temporarily storing its own user name when the terminal is used.
FIG. 17 is a flowchart showing login processing for temporarily storing the user name when the terminal is used. Each VoIP terminal 1 receives the user name when the user name is input when the terminal is used (step G1). Is temporarily stored as a login user (step G2).
[0050]
Now, in the state where “UserA” is registered as the user name in the VoIP terminal “A” and “UserB” is registered as the user name in the other VoIP terminal “B”, the VoIP terminal “A” is registered. When the VoIP terminal “B” is dialed, the IP address is combined with the “user name” in the telephone directory to make a call. Then, in the incoming VoIP terminal “B”, the “user name” currently used is compared with the “user name” combined with the IP address. Here, if the currently used user name is “UseraB” and the user name combined with the IP address is “UseraC”, an error response indicating that the user does not exist is sent because they are different. As a result, when the calling side VoIP terminal “A” calls as “UserB” as the user name, the VoIP terminal “B” matches the currently used user name, so an affirmative response is returned and a call can be made. .
[0051]
FIG. 18 is a flowchart showing call call processing (dial processing) executed by each VoIP terminal 1 side in the fourth embodiment.
First, when the VoIP terminal 1 accesses its own phone book file 10 and displays the destination name list screen, when a desired call destination is selected from the destination list screen, the selection is made. The telephone directory record corresponding to the other party is designated as a reading target (step H1). In this state, one of the IP addresses in the designated record is read according to the order of arrangement (step H2), and the “user name” of the call partner registered in the phone book file 10 is read. After combining the user name and the IP address (step H3), a call is made to this IP address according to RFC3261 (step H4).
[0052]
After the call is made, it is determined whether a time-out or an error response indicating that the user does not exist is returned (step H5). If neither of them is satisfied (NO in step H5), the process ends normally. However, if any one of them is satisfied, it is determined whether all IP addresses have been acquired from the telephone directory record corresponding to the selected party (step H6), and all IP addresses are acquired to make a call operation. If there is no response from the other party (YES in steps H5 and H6), the dialing process is terminated as a calling error.
[0053]
As described above, in the fourth embodiment, the currently used user name is temporarily stored for each VoIP terminal 1, and the user name is stored and managed for each destination in the phone book file 10. When the VoIP terminal 1 on the calling side sequentially reads out all the IP addresses associated with the call destination arbitrarily selected and designated from the telephone book file 10, the telephone book file 10 The VoIP terminal 1 on the receiving side joins the temporarily stored user name and the IP address from the VoIP terminal 1 on the sending side and transmits the call. The user name is compared with each other, and if the two are different, an error response is made, so that one VoIP terminal 1 can be shared and used by a plurality of users. It can be invoked to ensure the desired user as the call destination.
[0054]
The network telephone system in each embodiment described above is not limited to being applied to a very limited premises such as a company, but can be applied to a wide premises such as a region. Of course, the present invention can also be applied to a wide-area communication system.
[0055]
In addition, a recording medium (for example, a CD-ROM, a floppy disk, a RAM card, etc.) on which program codes for executing the above-described units are recorded may be provided to the computer.
That is, a recording medium having a program code that can be read by a computer, all assigned corresponding to a plurality of subnets for each telephone terminal that packet-converts input voice information and transmits it on the network. Function for storing and managing network addresses for each destination in the phone book data, and when a call partner is selected from the phone book, all network addresses are selected from the phone book data associated with the call partner. A computer-readable recording medium recording a program for realizing a function of sequentially reading addresses and a function of calling a telephone terminal of the other party on the basis of each read network address is provided. May be.
[0056]
【The invention's effect】
According to the present invention, in the state where the currently used user name is temporarily stored for each telephone terminal, and the user name is stored and managed by destination in the telephone directory, the calling telephone terminal When reading all the network addresses associated with the call destination arbitrarily selected and specified from the phone book, the user name in the phone book and the network address are combined and issued. The calling and called phone terminals compare the user name currently stored temporarily and the user name sent from the calling phone terminal combined with the network address, and they are different. In some cases, an error response is made, so that even when one telephone terminal is shared and usable by a plurality of users, a desired user can be reliably called as a call partner.
[Brief description of the drawings]
FIG. 1 is a block diagram showing the overall configuration of a network telephone system.
FIG. 2 is a diagram showing a relationship between a connection location of each VoIP terminal 1 managed on the DHCP server 2 side and an IP address assigned to each terminal corresponding to the location.
FIG. 3 is a diagram showing a configuration of a telephone directory file 10 managed on each VoIP terminal 1 side.
4 is a block diagram showing basic components of the VoIP terminal 1. FIG.
FIG. 5 is a flowchart showing telephone directory data creation / registration processing executed by the VoIP terminal 1 side;
FIG. 6 is a flowchart showing call calling processing (dial processing) executed by each VoIP terminal 1 side.
FIG. 7 is a view showing the structure of a phone book file 10 in the second embodiment.
FIG. 8 is a flowchart showing call call processing (dial processing) executed by each VoIP terminal 1 side in the second embodiment.
FIG. 9 is a diagram for explaining a modified application example of the second embodiment, and is a diagram showing contents of a schedule file SF used for automatically setting priorities and managing each person's action schedule;
FIG. 10 is a diagram for explaining a modified application example of the second embodiment, and is a flowchart showing an operation of the VoIP terminal 1 when automatic priority setting is performed with reference to a schedule file SF.
FIG. 11 is a block diagram showing a network telephone system in a third embodiment.
FIG. 12 is a diagram showing the structure of a phone book file 10 in the third embodiment.
FIG. 13 is a flowchart showing registration processing when the VoIP terminal 1 performs address registration with the SIP server 5 in the third embodiment.
FIG. 14 is a flowchart showing call call processing (dial processing) executed by each VoIP terminal 1 side in the third embodiment.
FIG. 15 is a view showing the structure of a telephone directory file 10 according to the fourth embodiment.
FIG. 16 is a diagram for explaining an operation outline of the fourth embodiment;
FIG. 17 is a flowchart showing login processing for temporarily storing a user name when using a terminal in the fourth embodiment.
FIG. 18 is a flowchart showing call call processing (dial processing) executed by each VoIP terminal 1 side in the fourth embodiment.
FIG. 19 is a diagram for schematically explaining a general SIP server;
[Explanation of symbols]
1 VoIP terminal
2 DHCP server
3 routers
4 access points
5 SIP server
10 Phonebook file
11 CPU
12 Storage device
14 Wireless LAN device
15 Input device
16 Display device
17 Microphone
18 Speaker
SF schedule file

Claims (2)

A network telephone system comprising a plurality of telephone terminals for packet-converting input voice information and transmitting it over a network,
The telephone terminal
A user name storage means for temporarily storing the user name currently used;
A telephone directory storage means for storing and managing all network addresses assigned to each telephone terminal corresponding to a plurality of subnets as telephone directory data for each destination, and storing and managing the user name together with the telephone directory data;
When a call destination is selected and specified from the phone book, all network addresses are sequentially read out from the phone book data associated with the call destination and registered in the phone book. Address reading means for reading out a user name,
Calling means for combining the user name with each network address read by the address reading means to call the telephone terminal of the call partner,
When there is an incoming call from the caller's phone terminal, the user name temporarily stored in the user name storage means is connected to the network address from the caller's phone terminal. An incoming means that compares the user name and responds with an error response if they are different,
A network telephone system comprising: Computer
User name storage means for temporarily storing the user name currently used,
A telephone book storage means for storing and managing all network addresses assigned to each telephone terminal corresponding to a plurality of subnets as telephone book data for each destination, and storing and managing the user names together;
When a call destination is selected and specified from the phone book, all network addresses are sequentially read out from the phone book data associated with the call destination and registered in the phone book. Address reading means for reading out a user name,
Calling means for combining the user name with each network address read by the address reading means to call the telephone terminal of the call partner,
When there is an incoming call from the caller's phone terminal, the user name temporarily stored in the user name storage means is connected to the network address from the caller's phone terminal. Incoming means that compares user names and responds with an error response if they are different,
Program to function as.

Images