SE517567C2 - Directing incoming calls - Google Patents

Abstract

The purpose of the present invention is to be able to route incoming calls in an efficient manner. The problem described with how to route incoming calls in an efficient manner is solved by diverting the incoming call to a service node which further diverts the call to a specific node in dependance of the telephone number of the called party in combination with other characteristics.

Description

In a similar manner, the user can make an outgoing call, using the gateway as a bridge between the IP-based Internet and the PSTN. In this situation, it looks from the PTSN network that the call comes from the gateway, and that it should be charged. A solution to this problem is presented in SE-9603932-6.

None of the above applications describe particular methods of routing incoming calls to the client in a manner that maximizes the use of the networks, both the telecommunications network and the IP-based network. Summary of the Invention The present invention describes a method and a network for solving the problem. routing of incoming calls for increased utilization of the networks.

The object of the present invention is therefore to be able to route incoming calls in an efficient manner.

The problem described above, how to route incoming calls in an efficient way is solved by redirecting incoming calls to a service node that redirects the call to a specific node depending on the called subscriber's number in combination with other characteristics.

In more detail, the above-mentioned problems are solved by redirecting the user's telephone number to a service node so that incoming calls will be routed to this service node. When the service node detects an incoming call, it analyzes the dialed number, where the user with that number is located and the position, or other characteristics, of the fl number of nodes and routes the incoming call depending on said analysis. The call is routed to a number denoting at least two voice gateways and for each incoming call, one of these at least two voice gateways is selected, to which the call is connected. The choice can be made, for example based on which voice gateway has the lowest workload or the geographical location of each voice gateway.

One of the advantages of the present invention is that the network is utilized in an efficient manner.

Another advantage is that the transmission time of the IP packets can be minimized, which reduces the disturbances in the service quality.

Other advantages will become apparent to those skilled in the art in light of the following detailed description.

Additional areas of use for the present invention will become apparent from the detailed description given hereinafter. It should be pointed out, however, that the preferred embodiments of the invention are described only as illustrations of the inventive idea, as a number of different changes and modifications within the scope of the invention will become apparent to those skilled in the art from this detailed description.

Brief description of the drawings Figure 1 shows the interfaces for "phone doubler".

Figure 2 shows a more detailed view of the network configuration for "phone doubler".

Figure 3 shows a network configuration for routing incoming calls.

Figure 4 shows a network configuration of another preferred embodiment.

Detailed Description of Preferred Embodiments Figure 1 shows a telephone doubler network and its external interfaces to external networks, users and devices. A user 101 is the one who uses the phone doubler at home.

The user 101 is also a subscriber to the service. An Integrated Services Digital Network (ISDN) 102 is used as a gateway to a Public Switched Telephone Network (PSTN) 103. A service provider (Service Provider - SP) 104 covers responsible systems, organization and people for the telephone doubler to work. Figure 1 also shows the internal structure of the phone doubler. A client 106 is the part of the phone doubler that the user has. A register 108 is the node in the gateway that is common to all users of the phone-doubler service. This node is called in the remainder of this document the registry. An Voice Gateway (VG) 107 is the device that handles all calls and voice transmissions. A VG 107 can handle a number of simultaneous calls. Figure 1 also shows the external interfaces to the network and the nodes. A user interface 109 is the interface between the user 101 and the client 106. An PRI interface 110 (ISDN Primary Rate Interface) is the interface used between voice gateway 107 and ISDN 102. An operation and maintenance interface (OMI) 111 is the interface between the service provider 104 and the register 108 and the voice gateway 107. A client gateway interface (CGI) 112 is the interface between the client 106 and the register 108, respectively the client and the voice gateway 107. A register interface 113 (Registry Interface - REGI) is the interface between register 108 and voice gateway 107.

Referring to Figure 2, the client 201 is run on a personal computer (not shown) connected to the access provider 207 of the service provider (ISP) at its Point of Presence (POP) via a modem 202 and PSTN 203. The personal computer receives an IP address from the ISP .

This is usually done dynamically when connecting to POP. In the preferred embodiment, ISP and SP 104 are the same organization or provider of services. Voice gateway 203, 204 is connected to the service provider's IP network, typically via Ethernet Ethernet 206 as POP. A plurality of voice gateways 203, 204 can be connected to the same POP. Each voice gateway 203, 204 is connected to ISDN 208 via PRI 209, 210. A register node 211, 212 may handle a plurality of voice gateways 203, 204. The register node 211, 212 may be remote. The voice gateway 203, 204 and the register 211, 212 are then typically connected to each other via the ISP's main IP network (backbone) 213. The host mode 211, 212 is usually duplicated for redundancy. A plurality of routers are denoted by R in Figure 2.

In Figure 3, a client 301 is connected to the IP network belonging to a service provider's IP network 302. For this connection, he uses a modem 303 and the PSTN network 304.

The PSTN network 304 is connected to the ISDN network 305 which in turn is connected to the service provider's IP network via a modem pool 306. The service provider's IP network is also connected to the Internet 307 via a router 308. A subscriber 309 calls the client 301 over the PSTN network 304 but will of course receive a busy signal if the client 301 has not forwarded his telephone. The client 301 has forwarded the telephone to an IN service contained in an SSCP 310. This could of course also be an SSP and a separate SCP, but for this embodiment an SSCP is sufficient. Two voice gateways 311 and 312 connect the ISDN network 305 to the service provider's IP network. The SSCP is continuously updated with the load situation for the various voice gateways and directs the incoming call to voice gateway 312, which currently has the lowest load. Through this procedure, the IP packets delivered from voice gateway 312 to the client 301 receive the least delay.

Figure 4 shows an embodiment for forwarding based on geographical position. In this situation, the longest part of the call is preferably in the PSTN network so that SSCP 401 forwards the incoming call from the subscriber 402 to the voice gateway 403 closest to the client 404.

The central register nodes can serve your distributed modules by voice gateways and constitute a distributed voice gateway for a larger area.

Distribution over large areas As long as the gateway contains a single group of voice gateways, all of which are connected to the POP accessory, it is easy to ensure sufficient throughput between modems and voice gateways. A single ISDN group number is also sufficient to serve all voice gateways.

When the phone doubler service is expanded to form a gateway for large areas, each POP has one or two voice gateways, which are handled by a central register node.

This ensures that voice traction is guaranteed to have minimal latency and jitter, as voice traction through routers is avoided.

Client data The client has the following data: 0 telephone number consisting of country code, area code] and local number. Example "46-08-6678054" 0 authorization data which according to this preferred embodiment is a One-way Function (ONF) applied to the country code, area code, local number and password (Optional. Permanent) 0 client IP address (unstable) 0 host name l for the register 0 host name 2 for the register 0 IP address of the first voice gateway (unsteady) 0 IP address of the second voice gateway (unsteady) 0 reject incoming calls (unsteady) All this data can be obtained during the login procedure, except for telephone numbers and authorization data.

The combination of country code, area code and local number is a unique identification of each subscriber. l is not needed in countries such as Denmark where area codes are not used 10 15 20 25 30 517 567 7 The VG IP address attribute also represents the client's status. An empty address indicates logged out, all other addresses indicate logged in.

REGISTER DATA Subscriber record Both register nodes have identical sets of subscriber records with the following attributes: 0 telephone number (key, persistent, consists of country code, area code and local number) 0 authorization data; an ONF applied to the telephone number merged with the password (persistent) 0 status; active or passive 0 client IP address (secondary key, inconsistent) 0 user identity (optional) 0 primary VG (inconsistent) 0 secondary VG (inconsistent) 0 number of logins (persistent) 0 number of incoming calls (persistent) 0 number of outgoing calls (persistent) ) 0 first login (persistent) 0 last login (persistent) The attributes of the client's IP address also represent the status of the subscriber record. An empty IP address represents logged out, all other addresses represent logged in.

E.164 IP Address Association When a user is connected to the Internet, the client's IP address is entered in the subscriber record in both registry modes. Since both the telephone number and this IP address are keys, the subscriber record contains an E. 164 IP address association between the telephone number and the IP address. 10 15 20 25 30 517 567 Register configuration data The following data can be configured in the register: Data that is identical in both nodes 0 mode for adding users; automatic or manual 0 automatic logout time (optional, must be longer than the timeout due to PPP not being active) 0 number of attempts with the password 0 automatic removal time (optional) 0 country code 0 area code 0 SMTP e-mail server (for e-mail-based alarm handling) ' 0 mail recipients (list of e-mail addresses to receive alarms) 0 synchronization host node; name of the synchronization host node (time synchronization host) Data unique to each register mode: 0 name of redundant register node (optional) 0 FTP account in the redundant register node '0 emergency number Data that can be the same in both nodes: 0 host nodes (hosts ) that has access to the WWW server 0 host nodes that have access to the FTP server VG mail The gateway configuration is determined by a number of Voice Gateway (VG) records. These entries are in the register and are updated at certain events such as when a VG is started or switched off. 10 15 20 25 30 517 567 IP address (key) name network with primary clients (only clients in these networks are served by this VG during normal operation) networks with secondary clients (clients in these networks can be served by this VG when another VG does not work) maximum number of logged in users current primary logged in users current secondary logged in users VG configuration data VG has a set of configuration data that is unique for each VG: pre fi x to call out IP addresses to the register. Possibly two if there is a redundant register monitoring interval method for extracting numbers (dials (A), dialed (B) or forwarding numbers) host nodes with access to the FTP server charging Login and logout functions: Purpose: To enable the user to connect to the ISP's POP using the telephone line and still be able to use the same line and number for incoming and outgoing calls.

The following addresses are important for these functions: the user's telephone number the client's IP address 10 15 20 25 30 517 567 10 0 the gateway's ISDN number General The login and logout functions are available in two variants depending on how the authorization mode attribute is set in the register configuration.

In automatic mode, the user is allowed to use the service if his IP address corresponds to the attributes of a client network in the VG records. In this case, you trust POP's authorization check, and the user has free hands when this has been done.

In this mode, debiting can only be done on IP addresses, ie. online billing. The phone number provided by the user cannot be trusted.

The second, manual mode means that the user must be registered in the system with some administrative procedure, see the subscriber management function. To use the service in this mode, users must also undergo an authorization check in the phone doubler system.

Authorization control is based on challenge responses (“challenge response mechanism”) (see Computer Communications Security, Warwick Ford, Prentice Hall, ISBN 0-13-799453-2). As ONF, the MDS algorithm (RSA Data Security, Inc. MD5 Message Digest Algorithm) can be used. ONF (X + Y) below denotes the application of the one-way function to the merged string X + Y.

Login in automatic mode This use case can only be used if the client's status is logged out. Prior to this use case, it is assumed that the user has set up forwarding or (better) forwarding when recording to VG's ISDN number. This can be done by telephone or in another way. Software for this is not provided in the product. In another embodiment, call forwarding is handled automatically by the service. 10 15 20 25 30 517 567 11 The client checks that the user's internet session is active. The client saves its current IP address in the client's attributes the client's IP address, for reference from other use cases (connect outgoing calls and logout). The client connects to the registry and transmits the user's telephone number. The registry retrieves the client's IP address as a parameter for the current TCP session. Note that the client's IP address will vary between phone doubler sessions if DHCP is used.

The register selects a VG and sends its IP address to the client. The selection of a VG is made by the registry as follows: (l) Select the VG records for which the user's IP address matches the primary client network attribute for VGzn. (2) Select the VG record that has the largest difference between the maximum number of logged in users and logged in primary users, (3) Check that the limit for the maximum number of logged in users will not be exceeded for the selected VG and (4) Check that the selected VG is not inactive. The attributes of the selected VG record for current primary logged in users are listed.

The register checks whether there is a subscriber record with the specified telephone number. It is checked that the client's IP address does not match any telephone number in the register at this stage. A check is made that the subscriber record's status is active and logged out.

The subscriber record is updated (the attributes of the client's IP address, number of logins and last login are updated). The PSTN-IP association is thus established and previous checks ensure that it is unambiguous in both directions. The attributes for current logged in users in the VG post are listed. The VG's IP address is entered in the client. The client disconnects from the registry.

If the internet session is not active, the user is prompted to start an internet session and try to log in again. If the register cannot be accessed, the user is informed of this and asked to try again later. The functions for incoming and outgoing calls are not available until the client has managed to log in. The user case ends.

If the client's IP address cannot be accepted according to any of the client network parameters in the VG records, the user case is terminated. No information is presented to the user, as this exception may be a case of illegal use.

If no VG is available, due to lack of resources, the user is informed of this. The client disconnects from the registry and the use case ends.

If there is no subscriber record for the telephone number the client has entered, a new subscriber record is created. The following attributes are filled in: telephone number, client's IP address, first login. Obvious default values are filled in for other attributes. Then this use case can continue. In another embodiment, no new user record is created, but the use case is terminated.

If, in the previous use case, the client's IP address is associated with a user's telephone number in the register, this association is of course invalid. In the case of use, forced logout is performed again for each such telephone number until no association is found from the client's IP address to any user's telephone number. Thereafter, this use case can continue.

If the subscriber record indicates that the user is already logged in (from a client's IP address), the use case is forced to log out. Thereafter, this use case can continue.

If the subscriber's status is inactive, the user is denied access and the user case is terminated.

Login in manual mode 10 15 20 25 30 517 567 13 The difference in this case is that the user must be fi initiated by the service provider before logging in. In the following, the additions to the automatic mode are described.

The client first requests to start the login procedure by signaling this to the registry. In this message, the phone number is transferred.

The register examines that a subscriber record, with this telephone number as a key, exists and retrieves a non-repeating value (NRV) and associates this NRV with the subscriber. This NRV is sent to the client who then responds with ONF (ONF (phone number + password) + NRV) NRv can be, e.g. emergency time in miuisekunaeff ONF (phone number + password) is either retrieved from the client configuration or calculated as a result of the password dialog with the user. The mechanism to be used is user-defined.

The register takes Authentication Data (AD) from the subscriber record and compares ONF (AD + NRV) with the value received from the client. If these values are equal, the user is authorized and a counter for errors in the authorization check is set to zero.

If the user does not appear, the user is informed that he must contact the service provider to register.

If the authorization check fails, the error check counter is counted up. If this counter exceeds the attribute number of attempts with the password, the user is deactivated. 10 15 20 25 30 517 567 14 If the user is already logged in, he is informed of this.

In all other parts, the exceptions from the automatic mode apply.

Logout, automatic mode The client checks that its status is logged in.

A reminder to disconnect the call forwarding is displayed to the user. Unfortunately, the call forwarding cannot be disconnected until the internet session is completed. This is outside the scope of the phone doubler product.

The use case forced logout is performed.

The client is disconnected from the registry.

If the client's status is not logged in, the use case is terminated without further action (disconnection of the client can continue).

If the register cannot be accessed, the use case is terminated. Disconnection of the client can continue. This results in an invalid association between the user's phone number and the client's IP address, which lasts until it is deleted by one of the uses login, automatic logout or connection of incoming calls.

Logout, manual mode The client checks that its status is logged in.

A reminder to disconnect the call forwarding is displayed to the user. Unfortunately, the call forwarding cannot be disconnected until the internet session is completed. This is outside the scope of the phone doubler product. 10 15 20 25 517 567 15 The use case forced logout is performed.

The client is disconnected from the registry.

If the client's status is not logged in, the use case is terminated without further action (disconnection of the client can continue).

If the register cannot be accessed, the use case is terminated. Disconnection of the client can continue. This leads to an invalid association between the user's telephone number and the client's IP address, which lasts until it is deleted through one of the use cases login, automatic logout or connection of incoming calls.

Forced logout Other usage cases that depend on this are login, logout, connection of incoming calls, automatic logout.

The association between the user's phone number and the client's IP address is terminated.

The subscriber's record is updated.

In the VG records, corresponding to the primary and secondary VG of the subscriber record, the current primary and secondary logged in users are counted down.

The registry log is updated.

Automatic logout This use case is performed periodically in the register without manual action. The purpose is to remove incorrect information from the subscriber records. The periodicity is given by the attribute automatic logout period in the register. It should not be too long, as it is in this way that a user who has been disconnected by mistake is given the opportunity to log in again. However, it must be longer than the disconnection time when PPP is not active in order not to interfere with this function in the ISP's Internet service.

Examine each subscriber record and perform the following steps: If the status of the subscriber record is logged in, verify that the client is actually alive by connecting to it. If the client is not alive, the use case performs forced logout for this subscriber.

If the client is alive but its telephone number does not match the attributes telephone number in the subscriber record, send the alarm inconsistent number during automatic logout and perform the forced logout for the subscriber in the use case.

If the client has not been logged in for a very long time (according to the period of automatic disconnection defined in the register), the subscriber record is deleted.

The relationship between the client's user interface and use cases The client's user interface is closely related to the use cases login and logout.

Once started, the client establishes a connection to the ISP's IP network, if this has not already been done by another application. The login usage case is then performed automatically.

The client's user interface also provides a menu option or buttons by which the user can request to log in. This is important, e.g. if the first login failed for some reason.

When the client is terminated, the logout use case is performed automatically.

Incoming call function 10 15 20 25 30 517 567 17 The incoming call function enables the user to be connected to POP via telephone line one and still be able to receive telephone calls on the same line as Hummel '.

The A-subscriber is the subscriber who calls the user's telephone number, which is forwarded to the LSD group number by a VG group. In another embodiment, the user's telephone number can be forwarded to an IN service.

Addresses The following addresses are important for this function: 0 the user's telephone number 0 the client's IP address 0 the A-subscriber's telephone number 0 the voice gateway's ISDN number Use case Connect incoming calls The A-subscriber dials the B-subscriber's telephone number which is forwarded to a universal number (Universal Access Number - UAN).

The call is based on the FREE interface. While the call is being connected, the B - subscriber's telephone number is extracted from the Q.93 1 signaling over the PRI. The type of number to be extracted is determined by the number extraction method.

If the parameter area code is available, its value is added in front of the B number.

The country code parameter is added in front of the B number.

The VG connects to the register and finds the subscriber record with the B-subscriber's telephone number. The client's IP address is retrieved from this record. 10 15 20 25 30 517 567 18 The VG disconnects from the register.

A connection is established to the client, with the IP address retrieved from the register.

The client indicates an incoming call to the user via the user interface.

The A-subscriber's telephone number is not presented.

Any of the following usage cases is then possible: 0 answer incoming calls 0 reject incoming calls 0 The A subscriber hangs up while calling 0 ISDN timeout while calling.

If the VG is inactive, it is signaled that the B-subscriber is included in the PRI and the use case is terminated.

If the B-subscriber's telephone number is not provided in the PRI, the call cannot be handled. Blocking is then signaled to the B-subscriber in PRI and the use case is terminated.

If the VG is unable to connect to the register and the register is redundant, this use case continues with the other register.

If the VG is not able to connect to the register, it is signaled that the B-subscriber is included in the PRI and the use case is terminated.

If there is no subscriber record for the provided B-number, the call cannot be handled. The VG disconnects from the register, it is signaled that the B-subscriber is included in the PRI and the use case is terminated. 10 15 20 25 517 567 19 If the B-subscriber's telephone number is not associated with an IP address, the VG disconnects from the register and the B-subscriber signals the busy PRI. The use case then ends. This exception occurs for a user who has logged out and forgot to disconnect the call forwarding.

If the establishment of a connection to the client at the specified IP address fails, it is signaled that the B-subscriber is included in the PRI. The use case then ends.

If the connection to the client is successful but the client's telephone number is not the same as the B - subscriber's telephone number, it is signaled that the B - subscriber is included in the PRI. The use case then ends.

If fl aggan reject incoming calls has been placed in the client, it is signaled that the B-subscriber is included in the PRI and the use case is terminated.

If the client software is busy, the B-subscriber signals busy in the PRI and the use case ends.

If the client cannot allocate an audio device, a message is presented to the user. This message informs him that there is an incoming call and that he has two options: (l) End the application that uses sound and answer the call or (2) Reject the call. If (2) is selected, it is signaled that the B-subscriber is included in the PRI and the use case is terminated. If (1) is selected, a new attempt is made to connect the call. If this attempt also fails because the audio device is not idle, the same message and options are presented again.

Answering an incoming call 10 15 20 25 30 517 567 20 This use case can only occur after an incoming call has been connected. The user chooses to answer the call. The client updates its status message. Speech transmission begins.

Reject an incoming call This use case can only occur after an incoming call has been connected.

The B-subscriber signals the busy PRI.

All resources allocated for the call are released in the client and in VG. The VG is disconnected from the client.

Incoming call, the A-subscriber hangs up while making a call This use case can only occur after an incoming call has been connected.

This use case is started from PRI.

All resources allocated for the call are released in the client and in VG. The user is informed that the A-subscriber has hung up.

The VG is disconnected from the client.

Incoming call, ISDN timeout while ringing This use case can only occur after an incoming call has been connected.

This use case is started from PRI. it occurs after a while if the B-subscriber (ie the phone doubler user) does not respond and the A-subscriber does not hang up. 10 15 20 25 30 517 567 21 All resources allocated for the call are released in the client and in VG. The user is informed that the call was disconnected.

The VG is disconnected from the client.

Incoming call, the B-subscriber hangs up during the call This use case can only occur when an incoming call has been answered, ie. when voice transmission has started.

All resources allocated for the call are released in the client and in VG, and it is signaled that the handset is on in PRI. The VG is disconnected from the client.

Incoming call, the A-subscriber hangs up during the call This use case can only occur when an incoming call has been answered, ie. when voice transmission has started.

This use case is started from PRI. All resources allocated for the call are released in the client and in VG.

The user is informed that the A-subscriber has hung up (VG does not wait for the user to confirm this message).

The VG is disconnected from the client.

Outgoing call function To allow a user to make outgoing telephone calls to the PSTN / ISDN while connected over the telephone line to the ISP's POP.

The following addresses are important for this function: 10 15 20 25 30 517 567 22 0 B-subscriber's telephone number v A-subscriber's IP address To understand how these addresses are handled, see the configuration management function.

Use cases The client performs a very limited number analysis of the B number.

Connect outgoing calls A prerequisite is that the client's status is logged in.

The A-subscriber dials the B-subscriber's telephone number. No number analysis is done in the client.

The client checks that its current IP address as reported by the operating system is the same as the previously saved attributes of the client's IP address.

The client checks if there is a free audio device on the client's platform and reserves it.

A connection is connected to the VG that was assigned to the client at login.

A check is made that the client's IP address can actually be served by the VG.

The dialed number is transferred to the VG. A very limited number analysis is performed as follows: If the parameter area code of VGtn is not empty, check that the first digits of the dialed number correspond to the area code.

If the dial-out parameter is present, its value is added in front of the dialed number. 10 15 20 25 30 517 567 23 An ISDN call is connected to the dialed number.

If the network billing parameter is true, the user's telephone number is signaled as the A number provided by the user in the PRI.

If the current IP address of the client differs from the previously saved attributes of the client's IP address, the client's status is set to logged out. The user is prompted to log in again and the use case ends. This situation can occur if a user logs in, the PPP connection stops working and a new PPP connection with a different IP address to the client is connected. If the client is unable to allocate any audio device, the user is informed of the reason and prompted to close any applications that use audio devices and try again.

If the connection to the VG cannot be established or if the VG's status is deactivated, the client tries to connect to the secondary VG. If this fails, the user is prompted to turn off the client and restart it (based on the theory that the user will then be assigned another and better suited VG). The audio device is released and the use case is terminated.

If the client's IP address is not accepted by the VG, an alarm rejected IP address is sent on outgoing calls. The audio device is released and the use case is terminated.

If the VG does not have available capacity, the user is informed of this and is asked to try later. An alarm VG capacity exceeded is sent out. The audio device is released and the use case is terminated.

If the VG's area code parameter is not empty and the first digits of the dialed number match the area code, it is checked whether the dialed number is an emergency number 10 15 20 25 30 517 567 24 more. If it is an emergency number, the use case continues, otherwise the user is informed that the number has an invalid format and the use case ends.

If the dialed number cannot be reached, the user is informed of the cause (busy, barred, etc.). The audio device is released and the use case is terminated.

Answering outgoing calls This use case can only occur after the use case to connect outgoing calls has been made.

The B-subscriber chooses to answer the call.

The client updates its status message.

Voice transmission begins.

Reject outgoing calls This use case can only occur after the use case to disconnect outgoing calls has been made.

The B-subscriber chooses to reject the call (as may occur if the B-subscriber uses a GSM telephone). VG sees a busy signal in PRI.

All resources allocated for the call are released in the client and VG. The user is informed that the B-subscriber did not respond (VG does not wait for the user to confirm this message).

VG disconnects from the client.

Outgoing calls, the A-subscriber hangs up while making a call 10 15 20 25 30 517 567 25 This use case can only occur after the use case to disconnect outgoing calls has been made.

The user hangs up before the B-subscriber has answered.

All resources allocated for the call are released in the client and VG. The user is informed that the B-subscriber did not respond. The status message in the client changes to free.

VG disconnects from the client.

Outgoing calls, ISDN timeout while it rings This use case can only occur after the use case to disconnect outgoing calls has been made.

This use case is started from PRI. It occurs after a while if the B-subscriber does not do something and the A-subscriber does not hang up.

All resources allocated for the call are released in the client and VG. The user is informed that the call was disconnected by the B-subscriber (VG does not wait for the user to confirm this message).

VG disconnects from the client.

Outgoing calls, the A-subscriber hangs up during the call Successful outgoing calls are usually ended in this way.

This use case can only occur after the outgoing call has been answered, ie. when voice transmission has been established. 10 15 20 25 517 567 26 All resources allocated to the call are released in the client and in the voice gateway.

The status message in the client is reset to the free message.

VG disconnects from the client.

Outgoing call, ISDN disconnection during the call This use case rarely occurs.

This use case can only occur after the outgoing call has been answered, ie. when voice transmission has been established.

The B-subscriber hangs up. After a while, the ISDN network disconnects the call (VG sees this in PRI).

All resources allocated to the call are released in the client and in the voice gateway.

The user is informed that the call was disconnected by the B-subscriber (VG does not wait for user confirmation of this message).

VG disconnects the client.

The subscriber management function To make it possible to administer the subscribers. The need for services is assumed to be small and consist of occasionally deleting a subscriber record whose password has been lost.

Usage cases Automatic deletion of subscribers The subscriber record for a user who does not log in for a very long time is deleted from the register. See the use case automatic logout under Error handling. This limits the user table in the register to consist of relatively active phone doubler users. A user who is removed from the registry can log in again at any time.

Add subscriber A management system can add specified users via the FTP interface in OMI.

A human administrator can add a specified user via the HTTP interface in OMI. Changes made to a registry mode are copied to the redundant registry mode.

Delete subscriber A management system can delete specified users via the FTP interface in OMI.

A human administrator can delete a specified user via the HTTP interface in OMI. Changes made to a registry mode are copied to the redundant registry mode.

Add and remove subscribers to the blacklist The subscriber status is set to disabled / enabled.

Can be done via HTTP and FTP. Change a subscriber's password.

Can be done via HTTP and FTP. 10 15 20 25 30 517 567 28 Subscriber analysis A human administrator can retrieve subscriber records via the HTTP interface in OMI.

Authorization check function The authorization check is described in the login and logout function.

To prevent unauthorized use of the service. In particular, to reduce the risk of someone entering another phone doubler user's number when logging in.

Billing function Billing is supported in a number of ways: Register log entries are generated and can be retrieved for the purpose of debiting forward fees or for statistical purposes.

Call log entries are generated and can be retrieved for the purpose of debiting For each call or for statistical purposes In manual add-on mode, users can be authorized to become valid users using phone numbers or user identities.

Users can be charged based on their IP addresses if the billing system can determine who uses a particular IP address at a particular time. This must be based on log from the access server and DHCP is used.

Incoming calls can be charged on the basis of service tariffs in UAN.

In manual add-on mode, outgoing calls can be made with the A-number specified by the user, which can be used in the telephone network billing system to charge outgoing calls. 10 15 517 567 29 Performance management function To enable SP to monitor and adjust the resource use of this service in the network.

Traffic in and out of the gateway is measured on the ISDN page. There are well-known tools and methods for this.

The register log can be used for statistical analysis of login and logout behavior.

The call log can be used as a complement to the ISDN tools to analyze the telephone behavior.

An alarm is sent if the capacity was exceeded during an outgoing call.

Having now described the invention, it is obvious that it can be varied in many ways. Such variations are not to be construed as deviations from the scope or basic idea of the invention, and all such modifications as are obvious to those skilled in the art are considered to fall within the scope of the following claims.

Claims (13)

10 15 20 25 517 567 30 Patent claims A method in a communication network comprising at least one data network (IP) and a telecommunication network (PSTN), which communication network comprises at least two voice gateways (VG) for adapting voice connections between the data network and the telecommunication network, in order to establish a connection to a subscriber connection. to the data network, comprising the following steps: - a service node in the network is instructed to connect all incoming calls to said subscriber to a number denoting at least two voice gateways, - for each incoming call to the subscriber the following is performed: - one of said at least two voice gateways are selected; - the call is connected to said selected voice gateway. A method according to claim 1, wherein the subscriber is connected directly to the data network via a fixed connection. The method of claim 1, wherein the subscriber is connected to the data network via modem, telecommunication network and an access server. A method according to claim 1 or wherein the communication network comprises at least two access servers for connecting computers to the data network via the telecommunication network. A method according to any one of the preceding claims, wherein the voice gateway having the lowest workload is selected as the most suitable. A method according to any one of claims 1-5, wherein the voice gateway is selected by which the transmission time of IP packets between said node and the subscriber is minimized. 10 15 20 25 30 5 1 7 5 6 7 31 A method according to any one of claims 3-5, wherein the voice gateway is selected which is closest to said remote access server used in the connection. A method according to any one of claims 1-4, wherein a voice gateway is selected by a service control point (SCP) node in an intelligent telecommunication network. Control mode for use in a communication network, which network comprises a telecommunication network and a data communication network, characterized in that it comprises: - means for receiving instructions from a service node in the telecommunication network comprising a number denoting at least two voice gateways; means for selecting one of the at least two voice gateways as the most suitable to which an incoming call to a subscriber connected to the data network is to be connected. The control mode of claim 9, comprising means for coupling the incoming call to the voice gateway having the lowest workload. 11. ll. Control mode according to claim 9 or 10, comprising means for connecting the call to the voice gateway with which the transmission time for IP packets between said node and the subscriber is minimized. A voice mode according to claim 9 or 10, including means for connecting the incoming call to the voice gateway closest to said remote access server. A communication network comprising at least one data network (IP) and a telecommunication network (PSTN), further comprising at least two voice gateways (VG) for adapting voice connections between the data network and the telecommunication network, characterized in that it comprises a control mode according to any one of claims 7- 10.