CN102365854B - Call barring in computer telephony systems - Google Patents

Abstract

This application deals with call barring. Typically, PBX systems have the ability to bar calls originating from both individual phones and groups of phones. However, PBX-based call barring solutions struggle to work with roaming/hot desks in large organizations that typically include many PBXs from different manufacturers. Therefore, a computer telephony based solution was chosen. Call barring is performed on a CTI server (1) that receives a request from a user to establish a call from a source telephone terminal (12) to a destination telephone terminal (8) through a computer terminal (10) . The CTI server allows or blocks the call setup request according to the call barring setting, and forwards the allowed call setup request to the PBX (4), so that the CTI server ignores the PBX call barring setting.

Description

Call Barring in Computer Telephony Systems

Generally, the present invention relates to the field of computer telephony and the supervision of call requests occurring in computer telephony networks.

Control of unauthorized calls placed from telephones in a corporate telephone system, such as a corporate telephone system comprising multiple telephones, has long been recognized as a problem. In a group environment, unauthorized phone calls pose a number of risks, which can come from several angles:

Costs (i.e. access to destinations with high tariffs: international, additional tariffs);

Time (i.e. work time spent on unauthorized personal calls);

• Regulations/compliance (ie unauthorized phone calls violate industry regulations).

Typically, telephone systems have the ability to bar calls originating from both individual phones and groups of phones. An inherent disadvantage in this type of system is that an individual who is assigned a phone that is barred by the application can try different phones around the organization until they find one that allows the desired type of calls.

To address this shortcoming, some PBX providers have introduced a concept whereby users can "register" on a phone of their choice using a unique authentication code (PIN). Upon registration, the phone effectively becomes theirs, ie the phone accepts their extension number and is assigned their personal settings, including their call barring status.

This is only a partial solution to the problem. User registration can be effective in small organizations such that all users share a properly equipped PBX. However, in large organizations there are often many PBXs, often from different manufacturers and versions, making it difficult to register any phone.

Another possible solution is to set up an automated desk service whereby individuals dial a specific number, identify themselves with a PIN, key in the number they wish to call, and, if that number is authorized for that user, the service The call will then be made on their behalf.

While effective, this is clearly a lengthy way of making calls, and has the very significant drawback that calls often happen in an automated fashion (like from a user's PC using a computer telephony client and contacts Directory, or instant messaging client applications such as OC (Microsoft's Office Communicator)). In a conventional CTI system, a user may use his computer terminal to request the establishment of an outgoing call from a telephone terminal registered in association with the user's computer terminal. The CTI controller responds to computer-originated requests by instructing the PBX serving the user's environment to establish a call from the appropriate telephone terminal. Clearly, if the phone associated with said client is by default in a state where certain calls (e.g. all chargeable calls) are barred to require the user to manually enter their security details into the desk service, then these automated call systems will can not work.

Current practices for call barring in a computer telephony environment are inadequate and problematic, and in an automated dialing environment, a method that allows call barring based on individual permissions is needed.

A system and corresponding method for supervising call requests originating in a computer telephony (CTI) system comprising a plurality of computer terminals and a plurality of telephone terminals is presented. The system for supervising call requests includes a store for storing a set of permissions associated with a user; and for storing a registration associating a computer terminal with a source telephone terminal. The system also includes a CTI server for receiving, via said computer terminal, a request from said user to establish a call from said source telephone terminal to a destination telephone terminal. The call setup request includes a user identifier associated with said set of permissions in the storage means. The CTI server is arranged to compare said call setup request with said set of permissions to allow or block said call depending on said permissions.

The method comprises: receiving at a CTI server, through one of said computer terminals, a request from said user to establish a call to a destination telephone terminal; wherein said request identifies said user. The CTI server compares the call setup request to the set of permissions associated with the user; and allows or blocks the call based on the permissions.

According to another aspect, the call request is associated with a source telephone terminal and a number identifying the destination telephone terminal; wherein the source telephone terminal is an extension of a PBX; wherein the CTI server forwards the allowed call request to the PBX. According to this further aspect, the PBX includes call barring settings associated with the source telephone terminal, wherein the CTI server adds a special prefix to the destination number before forwarding the call setup request to the PBX .

According to another aspect, the CTI server directs the PBX to route the requested call through a second PBX. According to another aspect, the second PBX allows or blocks the call based on a comparison of the call setup request and the set of permissions associated with the user. According to another aspect, the second PBX allows or blocks the call as a result of checking call verification data provided by the CTI server.

To facilitate understanding, embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:

Fig. 1 and Fig. 2 have shown the schematic diagram that provides the network that calls barring according to the present invention;

Figures 3a and 3b illustrate database schemas according to the present invention;

Fig. 4 shows a schematic diagram of a server for implementing the present invention.

A first embodiment will now be described with reference to FIG. 1 . As shown in FIG. 1 , a user 11 has access to a telephone terminal 12 and a processing device, such as a PC 5 . PC 5 can run a variety of applications, including web browsers, email clients, and associated software including client 10 . The client 10 is a client for an IM server 6 such as Office Communications Server (OCS) and Live Communications Server (LCS) both from Microsoft. A common add-on to web and email applications is a contact list. For IM applications, this contact list is sometimes referred to as the "buddy list", which is also included on the PC5. The telephone terminal 12 is connected to make telephone calls to the public telephone network (ISDN/PSTN network 9 ) through the local PBX 4 . The local PBX4 is connected to the ISDN/PSTN network 9 through the ISDN trunk line 13 . The telephone terminal 12 may be referred to as an extension of the local PBX 4 . Connect PC5 to CTI server 1 for initiating computer telephony events via LCS OCS server 6. The LCS OCS server 6 is associated with a database 6a such as Microsoft's Active Directory. The CTI server 1 is also connected to a local PBX 4 for implementing computer telephony events and to a database 2 (such as an Oracle database) for storing internal records related to computer telephony activities.

The interconnectivity between CTI server 1, database 2, LCSOCS server 6 and local PBX 4, and the interconnectivity between LCS OCS server 6 and Active Directory database 6a are provided through the company's internal data network 7 (such as Ethernet LAN).

In order to use an IM client (such as the OC client 10), first the user needs to authenticate himself on the client, usually by submitting a username and password, which are then collated by the OC server 6 in the database 6a Relevant records are maintained for inspection. Once the user is securely authenticated on the OC client 6, they also need to register the phone they want to use for CTI operations. This typically means that the user's credentials (such as username and password) are communicated to the CTI server 1 as part of the registration process, and it is authenticated against records held in the database 2 . International Patent Publications WO99/51015 and WO02/076071 of British Telecommunications disclose suitable methods of registering the identity of a telephone terminal in association with the identity of a computer terminal.

If the telephone registration was successful, the user 11 can now be considered authorized to control the telephone terminal 12 via the PC 5 and the CTI server 1 . When an authorized user initiates a request from the PC 5 to establish a phone call to another party (for example, by clicking on the "buddy" icon in the OC client 10), the request received by the CTI server 1 will contain the user's SIP URI and all Choose the destination number of good friend (all are embedded by OC client 10). The SIP URI provides the authenticated identification of the person wishing to make the call. The connection 7 between the CTI server 1 and the LCS server 6 is secured to avoid fraudulent use of the user's SIP URI, i.e. by the user at another computer. International Patent Publication WO2007/110567 by British Telecommunications describes how the extension number assigned to the phone of the user requesting the call can be identified from the SIP URI of the particular user.

How the user 11 establishes a telephone call through the CTI server 1 is now described. First, the user selects a destination (for example, colleagues or friends from a "buddy list"). According to this example, the destination happens to be a remote (ie international) telephone terminal 8 which, together with the local PBX 4 , has a connection to the ISDN/PSTN network 9 . Append the normal external dialing prefix (such as 9) to the destination directory number in the request. The user 11 passes through the IM client 10 and the LCS server 6 a telephony request identifying said destination to the CTI server 1 . To check the user's permission, the CTI server 1 searches the associated database 2 for the SIP URI received in said request from the user's IM client 10. The database 2 is pre-configured according to the calls allowed (i.e. with reference to the call barring table) for each user (as identified by the SIP URI in this example). The database 2 is also preconfigured according to prohibited destinations of the local PBX 4: normally these will be specified with reference to the PBX extension at which the call originates. In this example, said call barring table maintained in the database 2 indicates that the user 11 is allowed to make international calls. Next, the CTI server 1 instructs the local PBX 4 to set up a call from the extension registered to the user 11 , which is extension 12 in this example, to the desired destination. However, the traditional call barring applied by the local PBX 4 to the telephone terminal 12 may exclude international calls, such that the local PBX 4 will block the call even though the user is allowed to access the destination.

As shown in FIG. 1, a second ISDN trunk 14 from the local PBX4 to the ISDN/PSTN network 9 is configured. According to this method, the local PBX 4 supports all calls made on the second ISDN trunk 14, whether international or local. To provide a level of security, the second ISDN trunk 14 is assigned a special covert prefix known only to the CTI server 1 (eg "9229"). As mentioned above, if CTI Server 1 determines that the user is authorized to make international calls (i.e., as indicated by said call barring table in Database 2), CTI Server 1 automatically assigns the above special prefix (e.g., 9229) instead of A standard prefix (usually 9) is added to the dialed digits forwarded to the local PBX4. When the local PBX 4 receives said call setup request from the CTI server 1 , it acknowledges the presence of said special prefix by setting up the call via the second ISDN trunk 14 .

This approach achieves the desired subscriber-specific call barring, however, eg a malicious subscriber could try different prefixes until one is found which allows access to the second ISDN trunk 14 . Also, the prefix is actually visible on the display of extension 12, for example, if extension 12 is a PBX feature phone.

Another embodiment will now be described with reference to FIG. 2 . Figure 2 shows the same basic CTI system as Figure 1, but now with additional telephone switching equipment 3 - usually a PBX with special characteristics. For the purposes of this description, the telephone switching device 3 is referred to as an "added PBX", although in fact the telephone switching device could be an existing PBX with just the desired performance. PBX4 and PBX3 may comprise separate pieces of equipment or may be integrated as different functions within a single PBX. An example of the added PBX3 is described later.

Interconnectivity between PBX3 and PBX4 is provided through the internal company telephone network 15 . Increased interconnectivity between the PBX 3, the database 2 and the CTI server 1 is provided through an internal data network 7. The PBX 3 is also directly connected to the ISDN/PSTN network 9 via a trunk line 16 on which international calls are supported.

During the call setup process, the CTI server 1 checks to see if the destination number selected by the user via the client 10 is one of the numbers identified in the database 2 as prohibited by the local PBX 4 (eg a number for an international destination). If the CTI server 1 finds that the destination number selected by the user is prohibited, then no matter whether the extension 12 is completely prohibited or specifically prohibited, the CTI server 1 checks to see if it is in the user's call prohibition feature (profile) in the database 2. Record that destination number as an allowed destination.

If the user's call barring feature indicates that the user is not authorized to access restricted destinations, the CTI server 1 appends standard routing digits (eg "9") to the dialed digits. This standard routing number causes the call to be routed to the normal telephone exchange (ie the local PBX4) where the call will be blocked. If the user's call barring feature indicates that the user is authorized to access restricted destinations, the CTI server 1 needs to effectuate calls to destinations barred by the local PBX 4 . To effectuate the call, the CTI server 1 appends special routing digits (eg, "9229") to the normally dialed digits, as described above.

According to this embodiment, the special routing digits cause the call to be routed via the internal corporate telephone network 15 to the added PBX 3 . For example, the CTI server 1 usually requests the source extension 2000 to call the destination 94490014441234 from the PBX4 instead of the normal 90014441234. While the local PBX4 regards numbers starting with "900..." as being relevant to international destinations, it does not identify numbers starting with "9449..." as international and thus does not block the call.

According to a simplified embodiment, upon receiving a call from the local PBX4, the added PBX3 initiates a call to the destination 8 via PSTN/ISDN9 using SIP or ISDN messages. According to this simplified embodiment, the added PBX3 does not implement any further checks on the call request received from the local PBX4 associated with the "9449" number. According to this simplified embodiment, no interconnection is required between the added PBX 3 , the database 2 and the CTI server 1 . However, it will be safer if the added PBX3 implements the inspection that the call is allowed before initiating the call. Further embodiments providing such additional security checks will now be described.

The following embodiments will be described with reference to International Standard ECMA-269, "Services for Computer Supported Telecommunications Applications" (ECMA CSTA), 7th Edition, December 2006. Those skilled in the computer telephony field are familiar with ECMA CSTA.

According to this embodiment, as shown in Fig. 3a, the database 2 has two parts. One part is the permanent part 21, which records the permissions associated with the user. A second part is provided, a transient part 22, in which the CTI server 1 writes the permission details related to the current call. In more detail, the permanent part 21 includes a registered telephony terminal field 212 , a user ID field 214 and a permission field 216 . The temporary portion 22 includes a registered telephone terminal field 222 and a destination number field 224 .

When, in response to a specific CTI call setup request from a user, the CTI server 1 verifies whether, for a specific user, a specific destination number is allowed (i.e. with reference to the permanent part 22 of the database 2), the CTI server 1 associates these with the specific call request The permission details (for example, user 11, extension 12 and destination number 8) are written into the temporary part 22 of the database 2. According to this embodiment, call specific permission details are only kept in the database 2 for a relatively short period of time, say 10 seconds.

When the requested call arrives at the added PBX 3 , the added PBX 3 does not initiate the call immediately but, according to the present embodiment, first checks said call-specific permissions held in the temporary part 22 of the database 2 . This can be achieved as follows: For example, the added PBX3 (or the application program associated with it) performs SQL query to the database 2 directly or alternatively through the CTI server 1 . A query from the added PBX3 to the database 2 will need to identify the caller and proposed destination, however, the added PBX3 will only have access to the call parameters contained in the call request received from the local PBX4. These parameters are in turn limited to those parameters that the CTI server 1 can provide via the PBX 4 . The internal company telephone network 15 is unable to transfer the subscriber identity between the local PBX4 and the added PBX3 over the network, so that usually the combination of the extension number of the calling PBX extension 12 and the destination number remains. This will lead to the problem that during the course of a day, this combination may be easily reproducible, however, during the 10-second period of impose when entering the temporary part 22 of database 2, this combination has a high Possibilities are unique. As a result, by referring to the temporary part 22 of the database 2, the added PBX 3 is able to verify the high probability that the call request relates to a specific authenticated user, and thus can accurately identify whether the call is an authorized call or not.

Once the added PBX 3 has authenticated the call request, a call is initiated to the desired destination 8 via the trunk 16 and PSTN/ISDN 9 in the normal manner.

Typically, in an organization, employees may not have fixed desks, but can sit at any unoccupied desk, and will therefore use any available PBX extension at that desk. As a result, employees usually do not use the extensions permanently assigned to them, ie they have extension 3033 permanently assigned to them in the corporate directory, but today they just sit at extension 2000.

According to a further embodiment, in the SIP or ISDN message that the added PBX3 uses to initiate a call via PSTN/ISDN9, the added PBX3 may overwrite the extension number registered to the user with the extension number assigned to the user (eg, 3033) ( or CLI) (for example, 2000). Normally, both extension numbers are recorded in the permanent part 21 of the database 2 . The CTI server 1 has the details of the user 11 as a result of the authentication process (ie extension number 3033 assigned to the user) and as a result of the registration process (ie registration to the user extension number 2000). Therefore the added PBX 3 can obtain the extension number assigned to the user from the database 2 .

Finally, the added PBX 3 may mark the record of said call-specific permission in the temporary part 22 of the database 2 as relating to a "completed call", so that this particular, call-specific permission cannot be used in connection with another call , thereby avoiding illegal use by malicious users.

As an additional security measure it is possible to provide a range of numbers (routing numbers) for initiating calls via the added PBX3. For example, instead of only having access code 9449, a range of 20 codes, 9449 to 9469, could be used. As shown in FIG. 3 b , the database 2 is modified to include a field 226 for the access code in the temporary part 22 . With this additional security measure, when the CTI server 1 initiates a call via the added PBX 3, it can randomly select an access code from this range when initiating the call. The CTI server 1 writes the selected access code into the temporary part 22 of the database 2, so that when the added PBX 3 receives the call, it can match said access code received from the local PBX 4 against the database record. Obviously, a larger range of access codes would provide improved security.

As mentioned above, if the CTI server 1 rejects the call request, the CTI server 1 You can choose one of the following:

a) Initiate a call via the local PBX 4, where said CTI Server 1 will receive rejected ringtones (eg NU for UK);

b) No call is initiated (to save telephony resources), but appropriate CTI signaling is sent to the client 10 to indicate call failure. Typically a "CSTA Failed" (i.e., indicating that call progress has stalled, e.g., an outgoing call attempt encountered a busy endpoint); or

c) Ask the user for additional authentication information, ie a PIN or even a credit card number, using an IVR dialog (e.g. provided by the augmented PBX3).

The added PBX3, similar to the local PBX4, can be a traditional circuit-switched PBX, such as the Meridian of Nortel Networks Corporation in Toronto, Canada, or the SX2000 of MitelNetworks Corporation in Kanata, Ontario, Canada. Alternatively, it may be an IP telephony device such as VoIP AVVID from Cisco Systems, Inc. of San Jose, California, USA. The added PBX3 could be equivalent to a SIP server, an IVR server, or indeed any device that has a CTI interface and allows calls to be intercepted and controlled.

According to a further embodiment, the augmented PBX3 directs requests related to each call routed from the local PBX4 to the augmented PBX3 to the CSTA route point. The routing point responds to the receipt of the request from the added PBX3 by suspending the normal handling of the call by the PBX3 and by generating a CSTA routing request. PBX3 sends the CSTA routing request to CTI server 1, and through the added PBX3, CTI server 1 is set to be controlled by the routing of the call. The CTI server 1 checks with reference to the temporary part 2 of the database 2 whether the call is allowed.

As previously stated, the call request, and thus the CSTA routing request, typically contains an identification (eg, "ext 2000") and a destination number (eg, 94490014441234) of the calling device (eg, telephone terminal 12). Under the control of the CTI server 1, once a decision is made to allow the call (according to the user specific permissions in the database 2), the CTI server 1 replies to said CSTA routing request by sending back the CSTA routing to the added PBX 3. The CSTA routing contains the desired destination number (eg 0014441234) and the appropriate access code to initiate a call on trunk 16 from PBX3 to PSTN/ISDN9 (eg 9449). Advantageously, the additional access codes used by PBX3 to route calls to ISDN/PSTN9 will not be visible to users of extensions on the local PBX4, thereby increasing security.

An unauthorized user of device 12 accesses trunk 16 to access ISDN/PSTN9 capabilities will be limited by standard PBX routing constraints. Under the control of the CTI server 1, the CSTA routing point used can also be given permission for calls to unrestricted destinations.

Alternatively, the added PBX 3 may be a telephone platform with added software for controlling call routing. The way such devices route calls is known as a "dial plan." Commands can be added to the dial plan to: extract the appropriate dialed digits, query third party systems (ie, database 2 and/or CTI server 1 ), and make decisions on routing of calls. The adapted telephony platform intercepts the communication (ie, the incoming call request) and implements the procedures described above with reference to the augmented PBX3. A suitable telephony platform can be written based on a standard (such as the SIP standard) and using a suitable programming language (such as ANSI C).

According to an alternative simpler embodiment, the CTI server 1 does not write the access codes in the temporary part of the database 2 . According to this implementation, instead of checking the database 2 for an access code, the added PBX 3 uses the extension number (eg 2000) of the calling PBX extension 12 identified in the call request. The PBX 3 looks up the user's registered extension number (eg, 2000) in the database 2 and obtains permission from the user 11 associated with the registered extension number. The added PBX 3 then reads the destination number identified in the call request and checks whether the call specified in the call request is allowed.

In the description of the above embodiments, the CTI client is usually an IM client, which identifies the user through a SIP URI. However, there are other ways for a user to initiate a telephony request from the desktop. Typically, these can come from a web browser such as Mozilla Firefox or Microsoft Internet Explorer. The process by which calls initiated from a browser may benefit from the present invention will now be described.

When a user registers for URI based dialing, the user enters their username/password as part of the registration process. The server checks this username/password and if correct, the user is authenticated. The applicant's published international patent application WO2007/110567 covers a scheme for user registration, wherein a user's SIP URI is stored as a registration key, which is then used to identify said user in a computer telephony call request.

Earlier CTI-related solutions, as detailed in International Patent Publications WO99/51015 and WO02/076071, describe how to write a cookie that acts as a record of a user's registration and store it in the user's browser. When the user uses the "click to call" function to initiate a phone call from the web page to the selected number, a copy of the user registration cookie is sent to the CTI server 1 along with the call request. At this time, the CTI server 1 checks the content of the cookie using the original registration record kept in the database 2 . If a valid registration is found that matches the details contained in said cookie, the database 2 will record the authenticated username associated with that registration to allow the CTI server 1 to check whether the requested call is allowed (as in the calling user's ID and the Destination Number are dually defined). From this point of view, the process is as described above.

In the above description, only one community (local) PBX4 was considered (excluding the added PBX3). In fact, within a group, there may be dozens or even hundreds of such group PBXs. According to another embodiment, the CTI system of the present invention can be connected to any number of PBXs, thereby extending the benefits of CTI-controlled call barring in an enterprise-wide or other large-scale telephone system. Whilst the invention is most effective if all of these PBXs support CTI, an embodiment where one or more corporate (local) PBXs do not support CTI will now be described.

According to this embodiment, the local PBX4 does not support CTI, and the added PBX3 is used to set up the call. In more detail, according to this embodiment, the user 11 clicks on a buddy icon or link on a web page to initiate a call, as described above. The CTI server 1 receives the request from the user's PC 5 , and decides that the call is allowed based on the user's permission (ie, referring to the database 2 ). However, the CTI server 1 identifies that the extension indicated as the source of the call (ie the extension 12 registered with the user) does not have CTI functionality on the local PBX 4 to which it is currently connected. According to this embodiment, the CTI server 1 instructs the added PBX 3 to call the telephone terminal 12 registered with the user 11 . The user 11 answers the call from the added PBX 3 on the telephone terminal 12 . The added PBX 3 detects that the telephone terminal 12 goes off-hook and makes a call to the desired destination (for example, the telephone terminal 8 ).

incoming call barred

All the embodiments so far have described the invention in terms of outgoing calls. Dialed Number Identification Service (DNIS) is a telecommunications service that provides corporate subscribers with numbers dialed by callers. When an incoming call goes through the augmented PBX3, the number dialed by the caller can be extracted from the telephony signaling associated with the call using DNIS. The added PBX3 can identify the intended recipient from the number dialed by the caller. A suitably configured database is provided to allow the augmented PBX 3 to determine whether incoming calls from the source number identified by the information in said telephony signalling are allowed for a particular subscriber. According to another embodiment, call barring for incoming calls is further restricted according to other factors (eg time of day, etc.).

As will be understood by those skilled in the art, each of the above-mentioned PC 5, CTI server 1 and LCS OCS server 6 can be implemented as one or more commercially available servers or similar general-purpose processing devices, as shown in Figure 4 Show. Modern digital exchanges such as local PBX 4 and add-on telephone switching equipment 3 can similarly be based on a processor architecture as shown in FIG. 4 . FIG. 4 shows a typical architecture of a server according to another embodiment of the present invention, which is suitable for realizing the above-mentioned components of the computer telephony system. In practice, more than one such server is usually required. The server comprises a central processing unit (CPU) 40 for executing software programs and managing and controlling the operation of said processing means. The CPU 40 is connected by a bus 41 to a number of devices including one or more storage devices 42 (for example: hard drive, floppy drive, optical drive, and/or tape drive) for storing system and application software, and memory devices. (including ROM44 and RAM45). The server also includes a communication interface 47 for interfacing with external network components (eg, other components within the computer telephony system of FIG. 1 ). The server may also include user input/output devices such as a mouse and keyboard (not shown) connected to bus 41 through input/output port 46 and display 48 . Those skilled in the art can understand that the above architecture is just an example of a typical server architecture and not limiting. It is also to be understood that the server is described as having all necessary operating and application software to enable it to fulfill its purpose.

It will be understood by those skilled in the art that the present invention can be implemented in software loaded onto one or more general-purpose computers (such as the general-purpose computer shown in FIG. 4 ), any or all of the software is included in a computer program product, Such as a floppy disk, CD-ROM, or magnetic tape, so that the program can be loaded onto one or more general-purpose computers. A computer program product for implementing the invention may be implemented on any suitable carrier (such as CD-ROM, optically readable label, magnetic media) readable by suitable computer input means.

The embodiments described above can be understood as illustrative examples of the present invention. Other embodiments of the invention are contemplated and will be apparent to the reader in the art. It will be appreciated that any feature described in relation to any one embodiment may be used in combination with one or more features of the other embodiment or any combination of embodiments. Furthermore, equivalents or modifications not described above but defined in the appended claims may also be employed without departing from the scope of the present invention.

Although the above has been described in terms of telephony for reasons of clarity, the invention is equally relevant to other communication devices, such as applications featuring SIP. In addition to voice calls, the invention is equally applicable to the control of calls involving video or any other medium.

It should be noted that the number called may be different from the number the user selects on the display screen as the number to dial, ie adding an access code. The present invention can be used to hide certain number translations, eg according to company policy. The invention is not limited to corporate phone systems, but can be applied to any CTI phone system that includes more than one phone.

Claims (9)

1. a method for the call request in supervisory computers phone (CTI) system, described compuphone (CTI) system comprises multiple terminals and multiple telephone terminal, wherein user is associated with sets of permissions; Wherein said method comprises:

Receive from request described user, go to the calling of destination telephone terminal in order to foundation by a terminal in described terminal at cti server place;

Wherein, described setup requests identifies described user;

Wherein, the described sets of permissions that described cti server is associated by described setup requests with described user compares; And allow or stop described setup requests according to described license; Wherein said setup requests is associated with source telephone terminal and for the number that identifies described destination telephone terminal; Wherein said source telephone terminal is the extension set of PBX;

Wherein, the setup requests of permission is forwarded to described PBX by described cti server;

Wherein, described PBX comprises the call barring setting relevant to described source telephone terminal, and wherein in order to support described calling, described cti server, before described setup requests is forwarded to described PBX, adds special prefix to described destination number.

2. the method for claim 1, wherein described cti server, before described setup requests is forwarded to described PBX, changes destination number.

3. the method for claim 1, wherein described cti server guides described PBX to carry out by particular trunk the calling that route is asked.

4. the method for claim 1, wherein described cti server guides described PBX to carry out the calling of asking described in route by the 2nd PBX.

5. method as claimed in claim 4, wherein, the comparative result of the sets of permissions that described the 2nd PBX is associated according to described setup requests with described user, allows or stops described setup requests.

6. method as claimed in claim 4, wherein, described the 2nd PBX is according to the result that the call verification data that provided by described cti server are provided, allows or stops described setup requests.

7. the method for claim 1, wherein described setup requests is associated with source telephone terminal and for the number that identifies described destination telephone terminal; Wherein, the extension set that described source telephone terminal is a PBX; Wherein, described cti server order the 2nd PBX calls out described source telephone terminal 12 and described destination number to set up the calling of being asked.

8. the method as described in any one in claim 1 to 7, the method comprises:

Receive the notice from the incoming call of PBX at described cti server place, wherein, described notice comprises the mark in source and the destination number of described request of described request;

The user who utilizes described destination number to link in being identified at described CTI system at described cti server place;

The license that contrast is associated with identified user, the mark in the source of inspection described request; And

Based on the result of described inspection, stop or allow described calling.

9. a system for the call request of initiating in compuphone (CTI) system for supervision, wherein said computer telephony system comprises multiple terminals and multiple telephone terminal, wherein said system comprises:

Storage device, for storing the sets of permissions being associated with user; And for storing the registration that terminal is associated with source telephone terminal;

Cti server, for receiving by described terminal from request described user, in order to foundation from described source telephone terminal to the calling of destination telephone terminal;

Wherein, described setup requests comprises user identifier; Wherein, in described storage device, described identifier is associated with described sets of permissions; Wherein

Described cti server is arranged for described setup requests and described sets of permissions is compared; And

Allow or stop described setup requests according to described license;

Wherein, described setup requests is associated with described source telephone terminal and for the number that identifies described destination telephone terminal; Wherein, the extension set that described source telephone terminal is PBX; Wherein, described PBX comprises the call barring setting relevant to described source telephone terminal;

Wherein, described system also comprises:

Cti server interface, for allowed setup requests is forwarded to described PBX, and for before described setup requests is forwarded to described PBX, adds special prefix to described destination number.