A COMPONENT FOR PROCESSING IP TELEPHONY CALLS

Abstract: The invention enables an IP address to be "smuggled" through an existing CTI protocol and through the PBX to an IP Telephony Gateway (ITG) function by utilising a component to identify the Dialled Number as a special case which can be used "as is" by the ITG function to make the call to the specified IP address. The invention gets the IP address to the ITG function, which currently works off the DN (Dialled Number) from the switch, and resolves it on the ITG card to an IP address. Preferably, the number supplied to the PBX looks like an existing Dialled Number (DN). The conventional IP quad notation is padded to form a 3 digits per octet representation of the IP address and so eliminate the need to support the "." of usual dot notation within an IP address. By representing the IP address as a normal number with digits only in the range 0-9, it can also be entered by, for example, Call Centre Agents, via existing dial-pads and does not require either special characters to be transported across CTI links which might require changes to the CTI specification or adapting ITG function APIs.

Description: A Component for Processing IP Telephony Calls Field of the Invention The present invention relates to a telephony exchange component operable to process Internet telephony calls, a telephony exchange incorporating the component and a method operable in a telephony exchange. Background of the Invention IP Telephony Gateways (ITGs) are being deployed within private branch exchanges (PBX) or central offices (CO), for example, the Meridian M1 from Nortel Networks to provide toll bypass features for trunked calls. IP Telephony Gateways comprise a software function exposing an API, which can be called by software controlling the PBX, and an ITG card, which actually makes the connection to a required IP address. The conventional approach has been to make the operation of these IP Telephony Gateways transparent to end users and for IP addresses to be represented within the PBX in the form of conventional telephone numbers. When a call is routed, to an ITG card, the ITG function API therefore accepts a telephone number and, using a lookup table, indirectly translates this to an IP address before supplying the address to the ITG card. Thus, the ITG function translates E.164 style numbers dialled by a user at one endpoint, for example, 6 560 xxxx where xxxx is a four digit number, to IP addresses of other IP Telephony endpoints. It is true that the ITG function API could be extended to enable IP addresses to be sent directly to the ITG card to get it to make the IP telephony call. It will be seen, however, that the use of IP addresses at end-points and within a PBX would require massive reworking of PBX software. However, there is an emerging class of call scenarios, which require making a call to an actual IP address or its DNS name equivalent rather than a traditional dialled number, particularly in CTI (Computer Telephony Interface) and Call Centre type applications (and more specifically customer care centres which merge Web e-commerce sites with call centres). Referring now to Figure 1 , for an example of such a scenario, Nortel Networks' Internet Voice Button enables customers using a web client 10 to visit a business Web site 12 and to click a button 14 on a Web page to initiate a call to one of a number of Call Centre Agents 16, for example, to place an order, request service or ask for more information, without having to dial a number or leave their Internet session. Typically, the Call Centre Agent 16 uses, for example, a conventional telephone handset connected to a PBX (Private Branch Exchange) 30, for example, the Meridian M1 from Nortel Networks running conventional Call Centre software 32. When a customer clicks on a Voice Button icon on a business Web page, information is sent to a Voice Button (VB) server 18. This information includes a contact number to be called and the customer's calling preferences. A configuration screen collects information including the customer's preference for using either a standard PSTN phone, where the customer supplies a contact number in an E.164 format, or an IP Telephony call via the Internet, where the voice button application either automatically retrieves the customers IP address and supplies this as the contact number or the customer enters a DNS name corresponding to an IP telephony contact number. The VB server, acting as an adjunct server to the PBX, has a CTI link via service provider middleware 22 to the PBX Call Centre software 32 for conducting call control and can initiate the PSTN call backs from the PBX when requested by the customer. This is done by causing the call to be initiated to the customer whose number is then parsed by running it through a dialling plan 36. The dialling plan includes a set of route list blocks 38 and parses through the contact number, from left to right, to identify a route list block corresponding to the contact number. The route list block is then used to determine the circuit type and line card, usually either an ISDN or a Tied Line Card 40, 42, that should handle the call. When the customer answers this call, the call server initiates a second call to a Call Centre Agent which may go through an Automatic Call Distribution (ACDVCall Centre 34 routing stage. While, this side of the call is being established, a customized announcement may be played for the customer. At some stage, the Call Centre Agent answers the call and is connected with the customer. The issue is complicated when the customer sets a preference for the IP Telephony option. Conventionally, the VB Server implements it's own IP Telephony solution using ITG cards 24 to make the outbound call to the specified IP address and has a T1 link 26 or similar to bridge the IP call to the PBX 30, with each ITG card and Line Side T1 card requiring appropriate middleware to interface with the VB server. (Where a DNS name is supplied by the customer, the VB server obtains the IP address before making the call.) The VB server must implement the IP Telephony Gateway function itself, because it has no way of passing the IP address or DNS name it wishes to call to the PBX Call Server via a CTI "Make Call" feature. Since most PBXs now have built-in IP Telephony Gateways (ITG) cards 44 to implement toll bypass for outgoing calls, this is a re-implementation of an existing feature as a parallel infrastructure that is costly to develop, install and maintain. In an alternative solution, the VB Server hosts a H.323 gatekeeper functionality, which can make in-bound calls to the PBX/Central Office (CO) IP Telephony Gateway. This also requires extra infrastructure that is orthogonal to the VB Server's role of providing a value added service. In a further alternative, the various CTI protocols (e.g. TAPI from Microsoft, CT Connect, CSTA, etc) could be expanded to add specific support for IP Telephony calls. This, however, would entail a long lead-time on the rollout of protocol changes and many of the CTI protocols would have to go through their respective standards bodies to incorporate the changes. Then the PBX CO infrastructure would have to be upgraded to support the new protocol revisions. Disclosure of the Invention In a first aspect of the invention, there is provided a component for a telephony exchange said component being cooperable with exchange controlling software to parse numbers to be called and to determine a circuit type to be used for calling said numbers, wherein at least some of said numbers are directly indicative of Internet Protocol (IP) addresses and said component comprises a routing element defining a route to an IP telephony gateway for said numbers directly indicative of IP addresses so that said IP telephony gateway can obtain IP addresses for said numbers without reference to another data source. In a second aspect there is provided a telephony exchange comprising a plurality of line cards of one or more circuit types, including one or more IP telephony gateway cards, and exchange controlling software including a component cooperable with said exchange controlling software to parse numbers to be called and to determine a circuit type to be used for calling said numbers, wherein at least some of said numbers to be called are directly indicative of Internet Protocol (IP) addresses and said component comprises a routing element defining a route to an IP telephony gateway for said numbers directly indicative of IP addresses so that said IP telephony gateway can obtain IP addresses for said numbers without reference to another data source. In a third aspect there is provided a method operable in a telephony exchange comprising the steps of: receiving a number to be called, said number being directly indicative of an IP address; parsing said number in conjunction with a component comprising a routing element defining a route to an IP telephony gateway for said number, to determine an IP telephony gateway which is to handle said call; passing said number to said IP telephony gateway; deriving an IP address from said number; passing said number to an IP telephony gateway card; and establishing an IP telephony call to said IP address. In a fourth aspect there is provided an application server comprising a receiver for receiving an indicator of an IP address from a client wishing to establish an IP telephony call with a telephony exchange, a transformer for transforming said indicator of an IP address into a number in a computer telephony interface (CTI) compatible format directly indicative of said IP address, and a transmitter for transmitting said number using a CTI to an exchange in a request to establish a call to said number. In a fifth aspect there is provided a computer program for an application server, the program comprising a receiver for receiving an indicator of an IP address from a client wishing to establish an IP telephony call with a telephony exchange, a transformer for transforming said indicator of an IP address into a number in a computer telephony interface (CTI) compatible format directly indicative of said IP address, and a transmitter for transmitting said number using a CTI to an exchange in a request to establish a call to said number. In a sixth aspect there is provided a method operable in an application server comprising the steps of: receiving an indicator of an IP address from a client wishing to establish an IP telephony call with a telephony exchange, transforming said indicator of an IP address into a number in a computer telephony interface (CTI) compatible format directly indicative of said IP address; and transmitting said number using a CTI to an exchange in a request to establish a call to said number. In a seventh aspect there is provided an IP telephony gateway comprising: a receiver for receiving a number directly indicative of an IP address; an IP address generator adapted to derive an IP address from said number; and a transmitter for passing said number to an IP telephony card which is operative to establish an IP telephony call to said IP address. The invention enables an IP address to be "smuggled" through an existing CTI protocol and through the PBX to an ITG function by utilising a dialling plan to identify the Dialled Number as a special case which can be used "as is" by the ITG function to make the call to the specified IP address. The invention gets the IP address to the ITG function, which currently works off the DN (Dialled Number) from the switch, and resolves it on the ITG card to an IP address. The invention provides enables a single CTI interface to be provided to adjunct servers enabling a PBX to cover both PSTN and IP calls. Thus, using the invention, existing CTI protocols can be used to make IP Telephony calls using the in-built IP Telephony Gateways of the PBX or CO, without having to modify the CTI protocols or APIs. Thus, the IP Telephony call is no different to invoke than a normal PSTN call. This allows an adjunct server system such as a VB server to deliver only its value added service and not have to implement a separate and parallel IP telephony function, i.e. the VB server only requires a CTI link to the Call Server. It also concentrates all call processing functionality in the Call Server (PBX or CO) whether it is a PSTN or IP based call. Any IP Enabled PBX or CO implementing the invention and which supports call control via a CTI link can seamlessly support IP Telephony calls as if they were normal PSTN or local calls. This eliminates a complete set of functionality in adjunct servers that act as bridges for value added features and which need to simultaneously support IP Telephony and traditional telephony. The product cost savings as well as ease of development inherent in this approach are large, as well as enabling the Call Server to focus on call control while the adjunct server can focus on the value added service. Preferably, the number supplied to the PBX looks like an existing Dialled Number (DN). In a preferred embodiment, the conventional IP quad notation is padded by the VB server to form a 3 digits per octet representation of the IP address and so eliminate the need to support the "." of usual dot notation within an IP address. By representing the IP address as a normal number with digits only in the range 0-9, it can also be entered by, for example, Call Centre Agents, via existing dial-pads and does not require either special characters to be transported across CTI links which might require changes to the CTI specification or adapting ITG function APIs. Brief Description of the Drawings Embodiments of the invention will now be described with reference to the accompanying drawings, in which: Figure 1 is a schematic diagram of a conventional PSTN and IP telephony system; Figure 2 is a schematic diagram of a telephony system including a PBX according to the present invention; Figure 3 illustrates an exemplary dialling plan configuration according to the invention; and Figure 4 illustrates an ITG card dialling plan configuration operable with the dialling plan of Figure 3. Description of the Preferred Embodiments In a first embodiment of the invention, Figure 2, a VB server 18' rather than independently attempting to service IP telephony calls, pads the octets of the IP address supplied from the web client 10 in dot notation into a twelve digit number. The IP address dot notation address is thus transported using 3 digits for each octet of the IP address, so eliminating the need for a new key type to represent the dot in an IP address. In this embodiment, the VB server 18' also prepends the padded number with an access code required to conform to the dialling plan 36' in use at the PBX 30. Figure 3 shows an example dialling plan 36' for the PBX 30 where for example, dialled numbers are defined with a prefixed trunk type, 9-xxx-xxxx for PSTN calls and 6-xxx- xxxx for internally networked calls. The dialling plan is extended so that the access code 6 is used by the PBX for all non-PSTN calls including IP telephony calls. In the example, the access code 6 and ESN (Electronic Switched Network) location number 901 are used to identify IP address type numbers. The dialling plan is used by parsing through a dialled number or contact number from left to right in an attempt to identify a route list block for the number. In the case of conventional type ESN 560, the route list block will first test to determine if a TIED line circuit type is available. If not, the route list block will proceed to determine if an ITG circuit type is available. Many schemes may be used to select and determine which if any circuit types and line cards 40, 42, 44 should be used, for example, least cost routing or simply round robin. The dialling plan 36' includes a route list block for contact numbers detected as being IP telephony numbers - in this case it is numbers with an ESN location number of 901. In a dialling plan, where other ESNs are greater than 255, the need for an ESN could be obviated and any numbers beginning with a three digits less than 255 could be routed according to the ITG route list block. Alternatively, as explained below, a special access code of say 8 could be used to indicate IP telephony calls. In a further alternative, the length of the dialled digits following the access code could also be used to distinguish IP telephony numbers. In any case, the dialling plan will cause IP telephony contact numbers to be routed using this additional route list block defined within the dialling plan of the preferred embodiment. Thus, in the first example, when the PBX receives call back requests with an access code and ESN of 6 901 , it forwards the complete pre-pended and padded number to an ITG function which recognises the dial plan and takes the number as an IP address. It can then make the IP Telephony call to the desired endpoint. The ESN location number 901 is used, for IP telephony calls where there is a possibility of Tied Line ESN location numbers such as those for Galway and Maidenhead in the example, being numbered 001 to 255, as without the ESN there might be a conflict with the first of the IP address quads. However, a digit map could also be used within the call server to detect that TIED line numbers may only include less than 12 digits whereas IP telephony numbers may include more than 12 numbers, so obviating the need for pre-pending the IP telephony number with a special ESN. Thus, in the system of Figure 2, the VB server pre-pends the padded number originally obtained from the client machine with the numerals 6 901. The VB server then forwards requests for such calls comprising the padded and pre-pended number to the Call Server via a CTI link. (Thus, there is no need for the VB server ITG cards or T1 links of the prior art.) The Call Server operates with a dialling, which defines a routing for IP telephony calls. The dialling plan provides a definition of a specific numbering plan that passes the IP address of the end-point to be called through the PBX to the IP Telephony gateway. It is thus feasible to utilise conventional Computer Telephony Interfaces and existing Call Server (PBX or Central Office) infrastructure to make IP Telephony calls with no modification of the CTI protocols. The dialling plan causes the contact number to be forwarded to an IP telephony gateway/gatekeeper which is capable of directly dialling an IP Address using IP Telephony protocols such as H.323 or SIP (Session Initiation Protocol). When the IP telephony gateway sees this special number type it takes it as an IP address rather than an E.164 type dialled number. Thus, the gateway function API remains the same, and as such the call server software running the PBX remains unchanged, with only a minor modification of existing ITG function operation being required. Referring to Figure 4, the function conventionally expects to receive call requests for employing IP telephony for calls to inter alia the Maidenhead site at ESN location number 560. The gateway function would normally access a lookup table mapping the dialled number to an IP address and pass this IP address to the ITG card, which initiates an IP telephony call. However, when an IP endpoint having an IP address, 10.85.2.180, signals the Voice Button server, for example, through interaction with a web page including a voice button, and supplies its IP Address. The VB server translates this to 6 901 010085002180 and sends, for example, a Microsoft based TAPI message, which in turn is converted to a proprietary AML message, to the M1 PBX telling it to make a call between 6 901 010085002180 and an Agent. Using the dialling plan 36' the digits of the padded and pre-pended number are passed to the ITG function. The ITG function recognises this number as an IP address and re-converts the contact number to the original dotted quad IP address format. This is passed to the ITG card 44, which makes an IP call to IP Endpoint. As in the prior art, the server can wait until the customer has answered before establishing the agent side of the call. In another example, if the PBX uses a separate access code, for example, 8 to designate IP telephony calls, then the VB server pre-pends the padded number with the number 8. For example: 10.255.5.230 would equate to the IP Numbering Plan number 8-010255005230. In this case, the dialling plan 36' would include a third access code, and a single route list block would be associated with this access code. It should also be seen that it is not necessary to pass pre-pended portion of the contact number to the ITG function, as depending on the remainder of the dialling plan, this may not be necessary to enable the ITG card to distinguish between conventional ESN dialled numbers which can be mapped to respective IP addresses. Alternatively, the route list block can be used to select from a set of one or more ITG cards for use with contact numbers originally supplied in IP format while a second set of one or more ITG cards is dedicated to the conventional ESN dialled numbers which can be mapped to IP addresses. It should also be seen that the invention can be expanded to cater for the extra address space of IPv6 IP addresses. The Call Server, when it sees this prefix trunk type forwards the complete number to an IP Telephony Gateway interface. The Gateway then recognises this dialled number as an IP address type number and sets up the IP telephony call using the normal IP telephony protocols without having to do any Dialled Number to IP address mapping. Furthermore, the invention can be expanded to take into account different port numbers or different protocols, for example, H.323 or SIP, which may be required to perform an IP telephony call. In the former case, a user employing a handset may either add a port number directly to the end of the digits comprising the number indicative of the IP address, or the port number can be separated from the IP address portion of the number by one of any non-numeric characters available on a handset keypad, for example, * or #. So, for example, a user wishing to indicate that a call should be conducted on port 80 might dial - 6 901 010085002180#80. Alternatively, if the IP address is being provided from a web client to an application server such as the VB server, the application server could in fact add the #80 suffix to the number during or after the step of padding the IP address. In the latter case, the location code pre-pended to the number can be used to distinguish one IP telephony protocol from another. Thus, a location code of 90x where x is 1 or 2 could be used within a dialling plan to indicate location codes of 901 are to employ the H.323 protocol whereas location codes of 901 are to employ the SIP protocol. All such numbers may in fact be routed to the same ITG card which once it has derived the IP address from the number, can then use the distinct location codes to determine which protocol to employ. The invention has the further advantage that it enables both "dial by IP address" or "dial by DNS name" on a traditional PBX or CO infrastructure. "Dial by IP address" is enabled for agents using handsets connected directly to the PBX, by dialling the IP address with the specified number plan prefix followed by the 12 digit representation of the IP address described above. This can be done from existing telephone keypads without the need for special or new keys. It should also be noted that this embodiment of the invention does not require the presence of an adjunct server 18,18', and as such the scope of the invention should not be so limited. "Dial by DNS name" can be used both where clients supply a DNS name to the adjunct server 18' or where agents connect to the PBX using IP enabled handsets (not shown). The former case is enabled by letting the adjunct server 18' do the DNS lookup to resolve a DNS name e.g. www.smythjoe.dial might resolve to 10.244.20.230 which could then be dialled as if it were the simple Dialled Number 010244020230. In the latter case, the agent IP enabled handset has a simple IP stack that supports DNS lookup, it does not have to implement the more complex IP telephony feature - this is implemented by the Call Server in conjunction with the ITG function. This invention allows the same approach to be taken by the CTI link to all calls whether it is PSTN or IP Telephony call. The invention can be incorporated into most PBX/CO dial plans using scripts or standard dial plan creation tools. A small amount of development would have to take place on the IP Telephony Gateway subsystems, but this is trivial compared to changing CTI protocols. Finally, it should be seen that while the preferred embodiment has been described in terms of a Nortel Meridian M1 PBX, the invention is not limited to such an exchange and can equally be implemented on similar equipment. Thus, while the term dialling plan has been used in the description, it will be seen that variations of this term may be used in the industry, for example, "dial plan" or "numbering plan". Nonetheless, the invention may be embodied in any form where a number indicative of an IP address is received and directed to an IP Telephony Gateway where a call to the card is established.

Claims: Claims: 1. A component for a telephony exchange said component being cooperable with exchange controlling software to parse numbers to be called and to determine a circuit type to be used for calling said numbers, wherein at least some of said numbers are directly indicative of Internet Protocol (IP) addresses and said component comprises a routing element defining a route to an IP telephony gateway for said numbers directly indicative of IP addresses so that said IP telephony gateway can obtain IP addresses for said numbers without reference to another data source. 2. A component according to claim 1 wherein at least some others of said numbers to be called are indirectly indicative of IP addresses and said component comprises another routing element defining at least a route to an IP telephony gateway for said other numbers and wherein said IP telephony gateway is operable to obtain IP addresses for said numbers with reference to another data source. 3. A component according to claim 1 or claim 2 wherein said numbers directly indicative of IP addresses comprise a string of digits wherein groups of said digits correspond with respective octets of said IP addresses. 4. A component according to claim 3 wherein said numbers further comprise an access code indicative of said numbers being directly indicative of IP addresses. 5. A component according to claim 3 wherein said numbers comprise a location code within a dialling plan indicative of said numbers being directly indicative of IP addresses. 6. A component according to claim 1 or claim 2 wherein said numbers directly indicative of IP addresses comprise numbers of a pre-determined length. 7. A component according to claim 1 or claim 2 wherein said numbers directly indicative of IP addresses comprise a portion indicative of an IP telephony protocol to be employed in an IP telephony call. 8. A component according to claim 1 or claim 2 wherein said numbers directly indicative of IP addresses comprise a portion indicative of a port to be employed in an IP telephony call. 9. A component according to claim 1 or claim 2 wherein said numbers directly indicative of IP addresses comprise one or more non-numeric characters. 10. A component as claimed in claim 1 wherein said component comprises a dialling plan. 11. A component as claimed in claim 10 wherein said routing element comprises a route list block. 12. A telephony exchange comprising a plurality of line cards of one or more circuit types, including one or more IP telephony gateway cards, and exchange controlling software including a component cooperable with said exchange controlling software to parse numbers to be called and to determine a circuit type to be used for calling said numbers, wherein at least some of said numbers to be called are directly indicative of Internet Protocol (IP) addresses and said component comprises a routing element defining a route to an IP telephony gateway for said numbers directly indicative of IP addresses so that said IP telephony gateway can obtain IP addresses for said numbers without reference to another data source. 13. A telephony exchange as claimed in claim 12 wherein said exchange is a private branch exchange (PBX). 14. A method operable in a telephony exchange comprising the steps of: receiving a number to be called, said number being directly indicative of an Internet Protocol (IP) address; parsing said number in conjunction with a component comprising a routing element defining a route to an IP telephony gateway for said number, to determine an IP telephony gateway which is to handle said call; passing said number to said IP telephony gateway; deriving an IP address from said number; passing said number to an IP telephony gateway card; and establishing an IP telephony call to said IP address. 15. An application server comprising a receiver for receiving an indicator of an Internet Protocol (IP) address from a client wishing to establish an IP telephony call with a telephony exchange, a transformer for transforming said indicator of an IP address into a number in a computer telephony interface (CTI) compatible format directly indicative of said IP address, and a transmitter for transmitting said number using a CTI to an exchange in a request to establish a call to said number. 16. An application server according to claim 15 in which said indicator of an IP address is an IP address supplied from said client. 17. An application server according to claim 15 in which said indicator of an IP address is a domain name server (DNS) name and said application server comprises a retriever for retrieving an IP address corresponding to said DNS name. 18. An application server according to claim 15 in which said server is a web server and said client is a web client. 19. A computer program for an application server, the program comprising a receiver for receiving an indicator of an Internet Protocol (IP) address from a client wishing to establish an IP telephony call with a telephony exchange, a transformer for transforming said indicator of an IP address into a number in a computer telephony interface (CTI) compatible format directly indicative of said IP address, and a transmitter for transmitting said number using a CTI to an exchange in a request to establish a call to said number. 20. A method operable in an application server comprising the steps of: receiving an indicator of an Internet Protocol (IP) address from a client wishing to establish an IP telephony call with a telephony exchange, transforming said indicator of an IP address into a number in a computer telephony interface (CTI) compatible format directly indicative of said IP address; and transmitting said number using a CTI to an exchange in a request to establish a call to said number. 21. An Internet Protocol (IP) telephony gateway comprising: a receiver for receiving a number directly indicative of an IP address; an IP address generator adapted to derive an IP address from said number; and a transmitter for passing said number to an IP telephony card which is operative to establish an IP telephony call to said IP address.

Inventors: ELBERSE ARIK, QUINN BRIAN, SMYTH JOSEPH, ELBERSE, ARIK, QUINN, BRIAN, SMYTH, JOSEPH
Applicants: NORTEL NETWORKS LTD, NORTEL NETWORKS UK LTD, NORTEL NETWORKS LIMITED, NORTEL NETWORKS UK LIMITED
Application year: 2001
Main classification: H04M7
IPC codes: H04M3, H04M7