WO2001061968A2

WO2001061968A2 - Address translation and routing for internet telephony

Info

Publication number: WO2001061968A2
Application number: PCT/US2001/004805
Authority: WO
Inventors: Ayaz Jawad; Vohra Anurag
Original assignee: Xybridge Technologies, Inc.
Priority date: 2000-02-17
Filing date: 2001-02-14
Publication date: 2001-08-23
Also published as: AU2001239768A1; WO2001061947A1; WO2001061968A3; AU2001243156A1

Abstract

A call agent (1004) for routing calls through a data packet network (1016) communicates with or includes an address translation module (1008) that determines the address routing for a call and that enables the call agent (1004) to setup the call. The address translation module (1008) is formed to receive information about the source of the call and to determine how to route the call. Then, the address translation module (1008) communicates with the call agent (1004) to enable it to complete the call routing. Even if a called party cannot be reached purely by way of the Internet (1016), the address translation module is able to determine a media or signaling gateway to which the call can be routed by way of the Internet (1016) and from which a call may be generated over a public switched telephone network.

Description

TITLE: AN APPARATUS FOR A GEOGRAPHICALLY DISTRIUTED

SWITCH FOR TRANSLATING ADDRESSES AND FOR ROUTING A REQUESTED COMMUNICATION LINK SPECIFICATION

Background

CROSS REFERENCE TO RELATED APPLICATIONS This application incorporates by reference and is

related to Provisional Application for Patent entitled

method and apparatus IN A GEOGRAPHICALLY DISTRIBUTED

SWITCH for TRANSLATING ADDRESSES AND FOR ROUTING A

REQUESTED COMMUNICATION LINK filed on February 17, 2000

having a serial number 60/183,267.

1. Technical Field

The present invention relates to telecommunication networks, and, more particularly, to telecommunication switches .

2. Related Art

Current switch technology reliably routes calls from telephone to telephone through a communications network. A typical monolithic switch is formed to have the capacity for routing and connecting large numbers of calls. With today's rapidly expanding telecommunication industry, with the convergence of circuit switched and packet switched networks (exemplified by the Internet) , and the requirements to support plurality of access technologies such as PSTN, wireless, DSL, cable modem etc., current systems are not adequately flexible to reliably 'create communication links according to the needs of the user.

More particularly, a network convergence is taking place in which ^■ there is a need to reliably establish communication links through a plurality of communication networks according to the requirements of the calling party. As a part of this, there is a need to be able to route calls and to create communication links from end point to end point without, in the immediate future, replacing current systems and technologies with new and more flexible systems.

The worldwide network is particularly advantageous in that physical boundaries are not as recognizable and do not have the influence that they do in modern telephone networks in the public switch telephone network. For example, as will be shown in more detail later, national telephone networks are developed to only transmit international calls through specialized gateways from country to country. Thus, a user dialing an international call will have his or her call actually transmitted through a plurality of different switches including that which forms the international gateway prior to exiting his or her country and going into the destination country.

One reason that outgoing international calls are routed through and outgoing international gateway is that the intelligence for routing calls from nation to nation is embedded in those international gateways. Similarly, within regions of one nation, switches exist that serve as gateways from region to region. The intelligence for knowing which region a call is to be routed to is formed within the regional switches. As a serving central office receives the dialed digits, it analyzes the number of digits and format of the digits to determine the switches or gateways to which the call should be routed wherein the destination switch or gateway contains the necessary intelligence to complete the call routing. Thus, as may be seen, a hierarchical or tiered approach is implemented in conventional telephone systems for routing calls on an international basis or regional basis .

As the World Wide Web becomes a resource for telecommunications, it offers the possibility of expanding telecommunications options and for reducing the costs for long distance calls. An additional advantage is that the tiered topologies of the traditional telephone networks are avoided. One problem, however, is that current Internet based telephone systems do not have the intelligence that is necessary to perform proper call processing, especially on a regional or international basis .

What is needed therefore, is a method and apparatus to route calls and set up communication links in a way that satisfies a calling party's requirements for the communication link.

Summary of the Invention

A network convergence is taking place in which there is a need to reliably establish communication links through a plurality of communication networks according to the requirements of the calling party. As a part of this, there is a need to be able to route calls and to create communication links from end point to end point without, in the immediate future, replacing current systems and technologies with new and more flexible systems. A need further exists to integrate the operation public switched telephone network and private networks with Internet based telephone networks to reduce the price of transporting data and voice in a real-time basis for tolled communication links.

A system of the present invention includes a plurality of separate components that, collectively, have the functionality of a monolithic switch. A part of the system is a distributed Call Agent that is formed to analyze an incoming call or request for a communication link, to determine the type of device at the source or originating end, to analyze the destination and to determine the type of device to which the call or communication link will be terminated. Finally, the Call Agent is formed to determine a path route that best satisfies the calling parties requirements for the call or communication link. In one embodiment, the Call Agent includes a distributed address translation table and routing engine that performs the stated functionality. In another embodiment, the address translation and call route determination is performed in an external system.

The Call Agent of the described embodiment includes three functional blocks. Those blocks include an incoming address translation module, a route selection module, and an outgoing address translation module. Collectively, these three modules serve to analyze the source of a call and the digits dialed to properly interpret and respond to those dialed digits to route the call to the intended destination. These modules may be collocated or may be geographically separated but connected to operate as one system.

The incoming address translation module analyzes the dialed number, the originating gateway and the number type to generate a query to a database that includes address translation data. Based on the input parameters, the address translation module will receive a response to its query from the database holding the address translation data to produce a route directory number, as well as an address type and feature type for the numbers being dialed. These outputs from the input address translation module are then produced to a route selection module that also evaluates preferred network types, quality of serving ratings, cost specifications and potentially other parameters to actually ascertain the appropriate route string, terminating network type and terminating gateway name. These determined items are extracted by way of a query from a database that includes routing tables. The ordered list and other outputs of the route selection module are then produced at least partially to an outgoing address translation module. The outgoing address translation module, by analyzing the route number and the terminating gateway number, generates a query to an address translation data table within a database to determine the translated directory number.

As such, the Call Agent may perform the signaling for a call from an originating gateway to a terminating gateway. Thus, once the Call Agent communicates with the terminating gateway and reserves a port for receiving the call, that port information is transmitted back to the originating gateway device to enable it to identify and route the call to the terminating gateway.

The Address Translation and Routing Engine enables a geographically distributed switch to analyze any dialed number from any country with the dialing habits particular to that country and terminate it accordingly anywhere in its network. It simultaneously handles origination from public as well as any number of private networks under its domain. A process taking inputs like user preference of network type, carrier code, QOS, and least cost determines the terminating side. One can also configure each node in the geographically distributed switch to handle calls only in that country and for the National Destination Code (NDC) , where it is located or a set of NDC's for that country, or all NDC s in that country. With any of above condition the node may support another country, or set of countries or all countries. One may also define a set of special treatment numbers (feature codes) per node for which a separate action needs to be taken.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram of a traditional public switch telephone network (PSTN) in which international calls are set up by way of a plurality of international gateways.

FIGS. 2-7 are tables that illustrate the types of data that geographically distributed CA should be able to process to route a call .

FIG. 8 is a functional block diagram of a network formed according to one embodiment of the present invention.

FIG. 9 is a functional block diagram of a communication network formed according to one embodiment of the present invention.

FIG. 10 is a functional block diagram of a network including a Call Agent with an address translation and route selection module coupled to communicate with a plurality of media gateway devices according to one aspect of the present invention.

FIG. 11 is a functional block diagram of a Call Agent that includes an address translation and route selection module according to one embodiment of the present invention. FIG. 12 is a functional block diagram of a Call Agent formed according to an alternate embodiment of the present invention.

FIG. 13 is a functional block diagram of an incoming address translation module formed according to one embodiment of the present invention.

FIG. 14 is a functional block diagram of a route selection module.

FIG. 15 is a functional block diagram of an outgoing address translation module formed to produce a translated directory number that is used for routing the call according to one embodiment of the present invention.

FIG. 16 is a flow chart illustrating a method for address translation and call routing according to one embodiment of the present invention.

FIG. 17 is a flow chart illustrating a method for address translation and call routing according to one embodiment of the present invention.

FIG. 18 is a flow chart illustrating a method for address translation and call routing according to one embodiment of the present invention. FIG. 19 is a flow chart illustrating a method for setting up a call through a communication link that includes the Internet according to one embodiment of the present invention.

FIG. 20 is a flow chart illustrating one aspect of a method for processing a dialed number according to one embodiment of the present invention.

FIG. 21 is a flow chart illustrating another aspect of a method for processing a dialed number according to one embodiment of the present invention. FIG. 22 is a signal flow diagram that illustrates operation of a telecommunication network for two network calls according to one embodiment of the present invention.

Detailed Description of the Present Invention

FIG. 1 is a functional block diagram of a traditional public switch telephone network (PSTN) in which international calls are set up by way of a plurality of international gateways. Reviewing the topology shown in FIG. 1, an international gateway 102 that is within international borders 104 and 106 is coupled to set up all international calls going in and out of the country within the borders 104 and 106. For purposes herein, the country defined by borders 104 and 106 shall be labeled country A. Country B is exists between borders 106 and 108. As may be seen, country B also has one international gateway 110.

Within country A, at least one, and as shown herein, two Class 4 switches 112 and 114 are shown. Each Class 4 switch 112 and 114 is coupled to one or more local exchange carriers such as local exchange carrier (LEC)

116. In the system shown, LEC 116, as well as the other

LEC's 118, 120 and 122, are each coupled to a plurality of gateway systems such as private branch exchange (PBX)

124. As may be seen, a telephone 10 is coupled to communicate through PBX 124. As may also be seen, PBX

124 is also coupled to telephone 15. Accordingly, if a user of telephone 10 wishes to dial a user of telephone 15, then the user would only enter the digits for the extension for telephone 15. PBX 124, upon receiving the dialed digits representing telephone 15' s extension, would merely route the call directly to telephone 15.

In the network of FIG. 1, LEC 116 is not at all involved in the process of setting up a call between telephones 10 and 15. If, on the other hand, user of telephone 10 wishes to dial the user of telephone 20, then, as may be seen, the user would be required to dial a digit to get an outside line from PBX 124 which would then cause set up signals to be routed through LEC 116 to Class 4 switch 112 and then down to LEC 118 and then to PBX 126 where the call could be completed or terminated to telephone 20.

If, by way of example, telephone 10 were to place a call to telephone 25, then the call setup signals would be routed through LEC 116, Class 4 switch 112 and then directly to Class 4 switch 114 over line 128 before being routed down to LEC 122 to telephone 25. In most public switched telephone networks, the Class 4 switches such as switch 112 and switch 114 are, within the same borders, directly connected by a line such as line 128. This avoids the necessity for the call setup signals to be transmitted through international gateway 102 since each

Class 4 switch 112 and 114 serve different regions of the country that is served by international gateway 102. As may also be seen, if the caller of phone 10 wishes to reach a user at phone 30, then the call setup signals are routed through international gateway 102 into international gateway 110 and then down through Class 4 switch 130 and then to LEC 132 to gateway 136 and then to telephone 30 where the call is terminated.

As is understood, the call setup signals are transmitted from the gateways or PBXs such as PBX 124 and gateway 136 through the telephone network to set up the call. Only the actual trunk is connected from the gateway or PBX 124, or 136, respectively, to the LEC or gateway of telephones 10 and 30, respectively. Additionally, as in the case of telephone 25, an LEC often is connected directly to the terminating or originating phone without having an intermediate gateway there between. In such case, obviously, the call setup signaling does not go to a level lower than the LEC, such as LEC 122.

As described, above, the . various types of communication networks are converging to enable point-to- point call routing on a routine manner across the various networks. One approach to achieving the requirements for switching system that can accomplish the same is the separation of the functional components and the standardization of the interfaces from component to component (with the utilization of protocols such as MGCP (Media Gateway Control Protocol), IPST (IP Signaling Transport), LDAP (Lightweight Directory Access Protocol), SIP (Session Initiation Protocol), MEGACO (Media Gateway Control) etc.). This allows for a distributed, multi- vendor call processing architecture where functions such as Signaling Control, Media Processing, Mobility Control and Call control need not be co-located or provided from the same vendor source.

The completely converged network though inevitable, will not occur overnight. Incumbent service providers have multi-billion dollar investments in circuit switched voice infrastructure and associated network and service management systems. Their transition to IP networks will be evolutionary and has to occur in a fashion that protects infrastructure investments and maintains backward compatibility.

Therefore in order to provide feature transparency and ubiquity across network boundaries, the ability to seamlessly bridge the SS7, IP and various access networks is imperative. Bridging is required at two distinct interface points:

1. Access network to packet network interface 2. Circuit switched network to packet switched network interface

At each interface, bridging is required at multiple levels :

1. Media level - conversion between disparate media formats

2. Protocol level - inter-working between disparate signaling protocols

A multi network Call Agent formed according to one embodiment of the present invention is a scalable, extensible, call control framework that seamlessly bridges IP, Wireless, PSTN and SS7 networks and directory services. The Call Agent provides a service delivery platform that transcends international network boundaries and limitations and allows the creation of innovative services and business solutions that leverage network convergence .

An Address Translation and Routing Engine within a Call Agent (CA) enables a geographically distributed switch to analyze any dialed number from any country with the dialing habits particular to that country and terminate it accordingly anywhere in its network. It simultaneously handles origination from public as well as any number of private networks under its domain. It evaluates parameters including user preference of network type, carrier code, QoS, and least cost determines the terminating side. One can also configure each node in the geographically distributed switch to handle calls only in that country and for the National Destination Code (NDC), where it is located or a set of NDC's for that country, or all NDC's in that country. With any of above condition the node may support another country, or set of countries or all countries. One may also define a set of special treatment numbers per node for which a separate action needs to be taken.

As described in FIG. 1, existing gateways or switches handle calls either originating in a local area as a local exchange, or pass it on to a Class 4 tandem switch, which is programmed to handle switching between many such local exchange. Also there are international gateways, which handle and route calls to multiple countries, but the international gateway does not handle local calls or private numbers. The international gateway expects each number to be in International format (Country Code + National Destination Code + Subscriber Number sans any prefix or escape codes) . It may at the most accommodate the dialing habit of one country.

With advent of Voice over IP and soft switches, a switch may not be expected to conform to dialing habits of any one country. It not only should handle a set of private networks but also public networks in a host of countries simultaneously. The switch is no longer an integrated entity but is a geographically distributed one .

The address translation and routing engine of the CA solves the above problem. The logical flow and the set of data required for the solution are described in detail in the document. It is solved in a three-step process - analyzing incoming digits to give a routing directory number, determining the set of routes available, translating an outgoing address form a series of digits that are particular the route and destination networks.

In order to understand the working of the geographically distributed address transla tion and routing engine, it is helpful to understand the data stores involved in the providing these services.

FIGS. 2-7 are tables that illustrate the types of data that geographically distributed CA should be able to process to route a call. Referring now to FIG. 2, it may be seen that the country code is the combination of one, two or three digits characterizing the called country. For e.g., India's country code is 91. The two or three digits form the International prefix. The International prefix is the combination of digits to be dialed by a calling subscriber making a call to a subscriber in another country to obtain access to the automatic outgoing international equipment. The National prefix is a digit or combination of digits to be dialed by a calling subscriber, making a call to a subscriber in his own country but outside his own numbering area. It provides access to the automatic trunk equipment.

Referring now to FIG. 3, a Numbering Plan covers one "zone". There is a unique route table for each numbering plan in one embodiment of the invention. As may be seen, the public numbering plan is given one name while each private plan also is given a name. As will be seen, each numbering plan must be identified so that the intended interpretation of digits may be facilitated.

Referring now to FIG. 4, a Dial Plan Name can be specified at each gateway. It is always a part of a numbering plan. A given dial plan identifies its numbering plan, its feature table, and its access table. The feature table has a list of "special" numbers that trigger specified system responses. Different actions can be done on the basis of feature name given against a feature code. An Access Table is used to go from one private network to another or from private network to public network. It is present only if numbering plan type is private. For example, dialing a "9" routes a call from the private network through to the public network. Dialing an "81" routes the call to a specified private network. Here, that network is Private Network Y.

Referring now to FIG. 5, an Address Translation Data Table maps Gateway Domain Names/Addresses to a corresponding set of operational parameters. The operational parameters are a function of the network and its location. For example, if a calling party dials an "80" in a specified location, the digits signify that the call is to be routed to the country whose National Destination Code (NDC) is equal to "80". The Country code and Dial Plan are required for incoming address translation. The Country code, NDC, supported area code (SAC) , supported country code (SCC) and PBX Configured fields are required for outgoing address translation. The SAC is for defining what area codes in a defined area, such as an NDC, are supported. The value can be "all" to support all areas in that country. The SCC is supported country code to determine from what countries one can terminate a call to that gateway. Referring now to FIG. 6, a plurality of numbering plans is listed in the exemplary Routing Table of FIG. 6. It is understood that there can be as many Routing Tables as there are numbering plans. Each Routing Table is indexed by the numbering plan. Each numbering plan is given a Route Name and includes a Route DN, a Carrier Code, a Quality of Service rating, a cost factor, a terminating network type, a route string and a terminating gateway. The route tables are accessed by the Route Selection Module as described herein. The Route DN is the address of the next node in the network to which the signaling is to be routed. The carrier code identifies the carrier. The QoS rating is a user selected rating that determines the priority that a call gets through the network. The cost rating is an operator selected parameter, in one embodiment of the invention, that caps the cost for a given call or route. Stated differently, the cost parameter is used to exclude routes and communication links above a specified cost for a given user. The terminating network type is identified to enable the various nodes to make formatting decisions, if necessary. The route string actually defines the route that is to be taken and the terminating gateway defines the identity of the terminating gateways so that a given node may determine if it is to terminate the call or is to process it and transmit it to the next node in the call route.

Referring now to FIG. 7, the relationship between a plurality of gateways and the served parties are shown in one embodiment of the present invention. A gateway is like a node (or a point of presence) for the geographically distributed address translation and routing engine. FIG. 7 illustrates that any given gateway is coupled to route calls only to specified locations for the given gateway.

The origin and termination set of the Address translation and Routing Engine is the union of all the set of its gateways. Special treatment numbers may be defined on per gateway basis in its dial plan. For a public network, a gateway may be configured to terminate a call irrespective of international borders.

FIG. 8 is a functional block diagram of a network formed according to one embodiment of the present invention. Referring now to FIG. 8, a geographically distributed address translation and routing engine 804 is coupled to communicate with eight different gateway systems, each of which is formed to serve a defined role. For example, Gateway 1, as shown in FIG. 8 and in the table of FIG. 7, is for coupling a calling party anywhere within country A to anyone else within country A. Gateways 3, 5 and 7 on the other hand, are formed to only serve their own private networks and operate as PBXs. As may be seen, in the cases of countries having central offices, the Gateway is coupled between the central office and the geographically distributed address translation and routing engine 804.

One important point to note about the system of FIG. 8 is that it describes, as well as FIG. 7, the signaling aspects of setting up a call. Thus, if an individual in Country A seeks to place a call to an individual in Country F, then the signaling messages would be transmitted through Gateway 1, through the geographically distributed address translation and routing 804, and then to Gateway 8 and then to the Central Office of Country F by way of the Central Office of Country C. Once the respective ports have been assigned for the communication, the actual voice path of the call is carried directly by Internet from Country A to the specified port to country C. From country C, the call is transported over the PSTN to the Central Office of Country F. The outgoing address translation makes sure that the outgoing digits are in the format understood in country C. For e.g. International prefix in US is 011 and in India is 00. If a person calling Sri-Lanka from the US dials 011-94-XXX-XXXX, the call is transmitted by way of the Internet using media gateways in US and India. In India, the digits that need to be dialed are 00-94-XXX- XXXX. The Address Translation and routing engine (module) automatically determines the proper digit pattern for a call that is originated in India for the called party in Sri-Lanka after determining to route the call through the Internet to a gateway in India. Thus, the "dialed digits" that are generated by the Address Translation and routing engine are generated according to the point at which the call exits an Internet gateway to be transported over a telephone network. If, for example, the gateway is coupled to a private network in India, then the "dialed digits" that are generated are those that would be dialed if the call were being generated from a specified private network coupled to the gateway in India to the called party in Sri-Lanka. This operational logic thus is formed in the Address Translation and routing engine regardless of whether such engine is formed in hardware or in software when executed by a processor or a combination thereof.

FIG. 9 is a functional block diagram of a communication network formed according to one embodiment of the present invention. A communication network, shown generally at 900, includes a plurality of Call Agents, by example, Call Agent 902, that are each coupled to at least one media gateway. For example, Call Agent 902 is coupled to media gateways 904, 906 and 908. Call Agent 910 is coupled to media gateways 912, 914 and 916. Call Agent 918 is coupled to media gateways 920, 922 and 924 while Call Agent 926 is coupled to media gateways 928, 930 and 932. In each instance of a media gateway in the described embodiments herein, it is understood that a signaling way may be substituted therefor.

As may also be seen, each of the Call Agents is coupled to communicate with any of the other Call Agents. While the network 900 of FIG. 9 shows that Call Agent 902 is coupled to communicate with Call Agent 910 which is turn is also coupled to Call Agent 918 and Call Agent 918 is also coupled to Call Agent 926, it is understood that each of the shown Call Agents is coupled to communicate with all of the other Call Agents by way of the Internet.

In the present invention, the Call Agents are formed to be able to interpret the identity of the gateway device originating a communication signal and to determine its location as well as the location of a called party regardless of international boundaries. Thus, as is shown in the example of FIG. 9, Call Agent 902 is coupled to communicate directly with Call Agent 910 even though separated by international border 934. Similarly, Call Agent 918 is coupled to communicate directly with Call Agent 926 even though separated by international border 936. Finally, as will be explained in greater detail below in the discussion of Figure 10, Call Agent 902 also is capable of communicating with and routing calls to media or signaling gateways in other countries. For example, Call Agent 902 is able to communicate directly with media gateway 912 even then it is in another country or geographic area of a different Call Agent, namely, Call Agent 910.

The topology of network 900 is one that illustrates the call signaling relationships between the media gateways and the call agents. As is explained in greater detail elsewhere, the actual calls are routed directly from an originating media gateway to a terminating gateway once the call setup signaling is complete. Accordingly, the Call Agents are not within the actual call trunk or path.

FIG. 10 is a functional block diagram of a network including a Call Agent with an address translation and route selection module coupled to communicate with a plurality of media gateway devices according to one aspect of the present invention. As may be seen, a network 1000 comprises a Call Agent 1004 that, in turn, comprises an address translation and routing selection module 1008. Call Agent 1004 is coupled to communicate with a plurality of media/signaling gateways shown generally at 1012 by way of Internet 1016.

As may be seen, Call Agent 1004 communicates with media/signaling gateways that are geographically located within the same national boundaries and with media/signaling gateways that are located in other nations wherein the dashed line 1020 represents at least one international border between Call Agent 1004 and some of the media/signaling gateways with which it communicates. For exemplary purposes, a media/signaling gateway 1024 is coupled to a telephone 10 while a media/signaling gateway 1028 is coupled to a telephone 20.

As may be seen, media/signaling gateway 1028 is in a different international jurisdiction than media/signaling gateway 1024 and Call Agent 1004. Also, as is suggested by FIG. 10, media/signaling gateway 1024 and 1028 are coupled to communicate with each other by way of Internet 1016.

In operation, whenever a user of telephone 10 dials a plurality of digits to place a call to a called party at telephone 20, media/signaling gateway 1024 sends call signaling information to Call Agent 1004 by way of Internet 1016. The call signaling information includes a dialed number, the ID of the originating gateway, namely media/signaling gateway 1024, and an identification of the number type. Based upon these parameters, Call Agent 1004 identifies media/signaling gateway 1028 as the destination gateway for terminating the call to telephone 20 and generates call setup signals to media gateway 1028.

Media/signaling gateway 1028 responds with, among other things, an identification of a reserved port for the telephone call from telephone 10 by way of media/signaling gateway 1024. That information is transmitted from media/signaling gateway 1028 by way of Call Agent 1004 to media gateway 1024 in the signaling messages for setting up the call. Media/signaling gateway 1024 also generates communication signals specifying the reserved port address of media gateway 1028 by way of Internet 1016. In the described invention, the port is identified in the original set of call setup signals it generated. In another embodiment, the originating gateway port is not identified until after it determines the port address of the destination media/signaling gateway 1028. The important aspect here is that the originating media/signaling gateway port be specified prior to the beginning of a communication between the originating and destination media/signaling gateways .

As may be seen, the media/signaling gateways communicate with Call Agent 1004 with call signaling information thereby operating over an Internet based signaling plane. Thereafter, the actual voice/media path of the call is also set up through the same Internet. One function of Call Agent 1004 is to translate a plurality of dialed digits into Internet based addresses for call routing. Moreover, as will be explained in greater detail, a Call Agent, by intelligently analyzing the dialed digits in relation to the media gateway, is able to determine the serving gateway for the called party. As such, Call Agent 1004 may set up the call to the called party media gateway 1028 directly without having to interact with an international gateway as is the case in traditional SS7 and public switch telephone networks .

In one embodiment of the present invention, media gateway 1028 responds to the call setup signals received from Call Agent 1004. Call Agent 1004, in turn, completes the call setup by transmitting communication signals to media/signaling gateway 1024 advising it, among other things, of the specific port address to which the call signals are to be routed. This particular embodiment is advantageous in that it gives the Call Agent greater control over specifying the specific route and nodes through which a call is to be routed.

Alternatively, however, media gateway 1028 receives specific ID information regarding media gateway 1024 and responds by communicating directly with media gateway 1024 over Internet 1016 to complete the call set up. As may be seen, in this second embodiment, media/signaling gateways 1024 and 1028 are formed with a degree of intelligence to be able to perform such call setup processing. In the first embodiment, media/signaling gateways 1024 and 1028 may be formed with little or no network intelligence wherein they merely respond to specific queries by Call Agent 1004 to enable it to set up the call.

FIG. 11 is a functional block diagram of a Call Agent that includes an address translation and route selection module according to one embodiment of the present invention. As may be seen, the network shown includes a Call Agent 1100 that is coupled to a storage device 1108 and to the Internet 1112. Storage device 1108 comprises a database for storing address translation tables and a database for storing routing tables. In one embodiment of the invention, storage device 1108 further comprises a database that stores subscriber profiles for called and calling parties. > In another embodiment, subscriber profile data that is relevant to call set up is stored within the address translation and routing table databases. Media gateway 1116 and PSTN 1120 also are coupled to Internet 1112. Media gateway 1116 also is coupled to a telephone 10 while PSTN 1120 is coupled to a telephone 40. Media gateway 1124 also is coupled to Internet 1112. Media gateway 1124, in turn, is coupled to and serves telephone 20. It . is understood that the described embodiment illustrates a media gateway 1116 but that a signaling gateway may be substituted therefor.

Within Call Agent 1100, a processor 1104 is coupled to communicate and respond to an address translation engine that includes an incoming address translation module 1105, a route selection module 1106 and an outgoing address translation module 1107. Call Agent 1104 performs address translation in three steps, namely, incoming digit analysis, route selection and outgoing digit translation.

The Incoming Address Translation module is formed to receive a call setup signal indicating that a communication link is to be set up (or a call is to be routed) , which signal contains dialed digits and ID information. Upon receiving the call setup signal, the Incoming Address Translation module analyzes the call setup signal to determine the type of call (e.g., the number type), the destination address (e.g., the dialed number or IP address), and the type and ID of the originating Gateway. The Incoming Address Translation module then sends a query to a database to obtain corresponding address translation data.

The Incoming Address Translation module then outputs the address translation data. In the preferred embodiment of the invention, the Incoming Address Translation module outputs a route directory number (RDN) , an identification of the numbering plan type, an identification of a preferred routing table for defining the path route, an identification of the address type, and, if relevant, an identification of the feature type.

More specifically, the dialed number is, effectively, the called party address identified in traditional PSTN terminology (i.e., digits). The originating gateway is an ID of the gateway from which the call originated. This is important because the geographic location of the gateway must be known in order for the Call Agent to be able to properly interpret and respond to the dialed digits. The reason is that digits from different regions have different formats and thus can have different meanings for a given string of digits. For example, all dialed numbers can contain prefixes specific to the country where the gateway is logically located. One calling France from the US can dial 011-33- xxxx and from India one can dial 00-33-xxxx. One can also define a set of feature codes or special treatment numbers on a per gateway basis.

The incoming address translation module also receives a number type. The number type is one that identifies the calling party, as being a subscriber, a national call, an international call, or an unknown call.

After receiving the dialed number, originating gateway ID and number type, the incoming address translation module queries an address translation database that is stored within storage device 1108 to obtain a plurality of routing parameters. The routing parameters include the route directory number, the address type, the "in-NP-Type", the out-numbering plan index, and the feature type.

The route directory number is the normalized directory number against which an entry in a route table should be present. Additionally, the route directory number may also be a feature activation code if a call is not being dialed. The address type can be a feature or standard address type. The "in-NP-Type" is a definition of the numbering plan type, for example, private or public, of the originating gateway. For example of a public gateway, an E164 is a typical public originating gateway. The out-numbering plan index is a numbering plan index that is used to pick the route table. This number is only relevant if the address type is standard. The feature type can be, for example, something that identifies a call as a prepaid call, a collect call, a call forward activation, etc. This only has relevance if the address type is feature.

The route selection module (or the algorithm) for route selection takes into account a user' s carrier code (if specified), his preferred network type, and desired quality of service. The operator can assign to a user a cost parameter. The algorithm does not allocate a route above the assigned cost and below the desired quality of

service.

In operation, a Route Selection Module receives routing information for a communication link that is to be set up (or for a call that is to be routed) . Upon receiving the routing information, the Route Selection Module analyzes the contents of a routing tables database and selects a routing table that corresponds to and is appropriate for received routing information. By way of example, the Route Selection Module selects a routing table that is appropriate for or corresponds to the received route directory number, the routing table for defining the path route, the desired quality of service, range of acceptable costs, preferred network type, and a preferred carrier code.

To illustrate, for a given calling party, an identified routing table and desired quality of service might require a path route that provides the preferred network type at a higher cost. Alternatively, the specified QoS and the route table might result in a less preferred network type for the lowest cost. Moreover, as is understood by those skilled in the art, the variations also affect through amount of resource given to a communication path over a given path. For example, the amount of bandwidth, the end-to-end delay and other such Quality measures over a communication channel may vary according to each of the factors reviewed in selecting a "path route". The selected path is then defined by the ordered list of route string (e.g. endpoint name, IP address, trunk group name) , terminating network type (e.g. PSTN, H.323, SIP, MGCP, IPDC (IP Device Control) etc) , and the name of the terminating gateway.

The outputs of the Route Selection Module include an ordered list of routes, i.e., a route string. The route string can be an end-point name, an IP address, or a trunk group name, each of which can then be mapped to an input name by some other entity. The output of the Route Selection Module also includes a definition of the terminating network type. The terminating network type can be PSTN, H.323, SIP, MGCP, and IPDC.

The input of the Route Selection Module includes the route directory number, a quality of service rating (optional), a definition of cost (optional), a preferred network type (optional), an out-NPI, and a carrier code. The route directory number is the output of the address translation table. It is a number with CC and NDC for E164 route table.

The quality of service rating is one that is specified by a subscriber. In one embodiment of the present invention, the quality of service desired by subscriber is rated with a number in the range of 1-5. If the subscriber does not care, a value of 6 is assigned as a quality of service rating. With respect to the cost, a scale level of cost that may be assigned by the user is specified herein. Thus, in one embodiment of the present invention, cost defines the maximum cost that the user is willing to pay for the communication.

The preferred network type is, again, a user specified preference. It may take on values of preferably IP, only IP, preferably PSTN, or only PSTN. The out-NPI is the index to the route table that is to be used. This is a value that is received from the address translation module. The carrier code takes on values as lOxxx. This, again, is a user specified preference and is used for identifying a preferred long distance carrier.

The outgoing address translation module is responsible for specifying the route that the communication is to take. More specifically, the inputs to the outgoing address transaction table include the route directory number that is an output of the incoming address translation module and an identity of the gateway where the call needs to be terminated. The outgoing address translation module then queries the data store 1108 or another date store containing address translation data for use by the outgoing address translation module. From the results of the query to the data store 1108, the outgoing address translation module produces a translated destination number that is a digit string that is to be dialed out to reach the destination number. This digit string, obviously, depends upon the route that is chosen for the communication link.

FIG. 12 is a functional block diagram of a Call

Agent formed according to an alternate embodiment of the present invention. Call Agent 1200 includes an incoming address translation module 1204, a route selection module 1208 and an outgoing address translation module 1212. As may be seen, however, the incoming address translation module 1204, the route selection module 1208 and the outgoing address translation module 1212 are not co- located. They communicate with each other by way of Internet 1216. Each of these modules further communicates with a storage device 1220 by way of Internet 1216. Other than the fact that this embodiment of the Call Agent 1200 includes a geographically disbursed set of modules, its operation is the same as described here in this application.

FIG. 13 is a functional block diagram of an incoming address translation module formed according to one embodiment of the present invention. An incoming address translation module 1300 includes circuitry that forms an IAT operational logic circuitry 1304, database protocol logic circuitry 1308 for accessing the database within memory 1324, IP protocol and corresponding logic circuitry 1312 and output data formatting logic circuitry 1316.

The incoming address translation module 1300 further includes a plurality of network ports 1320 to enable it to communicate with other systems by way of the Internet utilizing the IP protocol logic circuitry 1312 and with other external systems such as external data stores that include address translation data tables or data.

In the embodiment shown in FIG. 13, incoming address translation module 1300 further comprises memory 1324 that defines address translation data. In one embodiment of the present invention, memory 1324 only stores address translation data on a temporary basis as it is received by way of network ports 1320 from an external storage device .

In another embodiment of the invention, an actual database is formed as a part of incoming address translation module 1300 within memory 1324. Accordingly, the database protocol logic circuitry 1308 communicates directly with the internal database in memory 1324 to obtain address translation data.

In the first embodiment, wherein the address translation data is formed within an external storage device, the database protocol logic circuitry 1308 communicates with the database of the external storage device to obtain the address translation data. IAT operational logic circuitry 1304 comprises logic to analyze the incoming signals from the media gateway for a call that is to be set up to determine the dialed number, the originating gateway and the number type and, responsive thereto, to generate a query to obtain address translation data. As mentioned before, the query may be either to a database that is formed within and is a part of IAT 1300 or in an external storage device.

Upon receiving the address translation data from memory 1324, IAT operational logic circuitry 1304 determines the route directory number, the numbering plan type, the numbering plan index that is used to select a route table, and the feature type, if relevant, introduces that data to the output data formatting logic circuitry 1316 where it is output in a specified format for delivery to the route selection module external to the incoming address translation module 1300.

Whenever incoming address translation module 1300 receives a communication signal that includes a dialed number, the IAT operational logic circuitry 1304 communicates with IP protocol logic 1312 to receive and interpret the data contents within the communication signals since they are received by way of the Internet through the network port 1320. The IAT operational logic circuitry 1304 then extracts the dialed number, the originating gateway ID and the number type to formulate a query that is to be transmitted to memory 1304 to obtain the desired address translation data. The query is formed, in part, by logic defined within the database protocol logic circuitry 1304. Once the response to the query is received from memory 1324, the response containing address translation data, the operational logic circuitry 1304 communicates with output data formatting logic circuitry 1316 to produce the outputs of the IAT 1300 as described already. While IAT 1300 is formed in hardware with logic circuitry in the described embodiment, the circuitry may alternatively comprise a processor and computer instructions stored within memory that logically create the described modules and their operational logic.

FIG. 14 is a functional block diagram of a route selection module. Route selection module 1400 comprises route selection logic circuitry 1404, IP protocol logic circuitry 1408, output data formatting logic circuitry 1412, network ports 1416, and memory 1420 that defines routing tables. As with the system of FIG. 13, memory 1420 may either comprise temporary storage registers for storing routing table information that is received from an external storage device or, alternately, may comprise sufficient types of memory that are adequate for actually storing and maintaining the routing tables within and as a part of route selection module 1400. In operation, route selection module 1400 receives signaling generated by IAT 1300, for example, defining the route directory number, the carrier code, the preferred network type, the quality of service rating, cost parameters, and the index to the route table that is to be used. In an embodiment wherein the incoming address translation module 1300 is formed in a geographically distinct location, wherein the incoming address translation module 1300 and a route selection module 1400 communicate by way of the Internet, route selection module 1400 utilizes IP protocol logic circuitry 1408 to receive the information from incoming address translation module 1300. Route selection logic circuitry 1404 then forms a query that is transmitted to memory 1420 to obtain specific routing information from either the temporary or permanent data, according to embodiment, stored within memory 1420.

Route selection logic circuitry 1404 then communicates with output data formatting logic circuitry 1412 to produce a route string that comprises an in point name, an IP address name, or a trunk group name that can then be mapped to an in point name by some other entity. The output data formatting logic also specifies the network type for the route, which network type can be PSTN, H.323, SIP, MGCP, IPDC or other known network types .

FIG. 15 is a functional block diagram of an outgoing address translation module formed to produce a translated directory number that is used for routing the call according to one embodiment of the present invention. An outgoing address translation module 1500 comprises outgoing address translation operation logic circuitry 1504, IP protocol logic circuitry 1508, output data formatting logic 1512, at least one network port 1516, and a memory 1520 for storing address translation data.

As before, the outgoing address translation module 1500 may be formed in hardware or in software wherein the modules in circuitry within that define the operational logic of the system are instead created by software modules that are generated when computer instructions stored in memory are executed by a processor. Outgoing address translation operational logic circuitry 1504 includes logic for receiving a route directory number that is the output of the incoming address translation and an ID of the terminating gateway. Based upon that data, the outgoing address translation operational logic circuitry forms a query to receive address translation data from memory 1520. As before, memory 1520 may comprises temporary memory buffers for temporarily storing address translation data that is received from an external storage device that houses a database of address translation data or, alternatively, can comprise memory within the outgoing address translation circuitry that is capable to form and store the actual address translation database. The output data formatting logic circuitry 1512 then is formed to receive the address translation data from memory 1520 and to format the same according to an appropriate protocol for the destination gateway. Thereafter, the IP protocol logic circuitry 1508 forms IP data packets with the appropriate headers to route the call to the node characterized by the translated directory number as a part of routing the call to the destination gateway.

FIG. 16 is a flow chart illustrating a method for address translation and call routing according to one embodiment of the present invention. Referring now to FIG. 16, an Incoming Address Translation (IAT) module receives call setup signals from a media gateway (step 1604) . The call setup signals include signals that represent the dialed digits, number type and originating gateway ID. Accordingly, the IAT module extracts the data from the call set up signal and determines the gateway ID (step 1608) . In one embodiment, the gateway ID is used to determine location of the gateway wherein the location may be used for determining how to interpret digit entries. In an alternate embodiment, the ID is used to identify a network or operator or other grouping indicator wherein the network, operator or other grouping indicator is used to determine proper digit interpretation. For example, a given operator may well have gateways in different international jurisdictions or even regions (Class 4, for example) that are all formed to operate similarly.

In the described embodiment, the location must be determined at least to an extent that it enables the IAT module to correctly interpret the intended meaning/result from the sequence of digits. For example, a given feature may have different number feature codes or key sequences that are used to activate the given feature in different geographic areas according to the country, the service provider, etc.

The IAT module also analyzes the dialed digits and number type as a part of interpreting them and determining the user's intended result (step 1612). A method for interpreting the dialed digits is illustrated in the discussion of FIG. 19, below. In general, however, interpreting the dialed digits includes determining a calling plan and a location of the serving gateway for the calling party so that the context of the digits may be understood. For example, if the first three digits are "Oil" and the call is being placed in the United States, the Call Agent may properly conclude that a call is being placed to an international jurisdiction (outside the U.S.).

After the Call Agent has determined and analyzed the dialed digits, it transmits a query to an Address Translation database to obtain address translation data (step 1616) . Responsive thereto, it receives, in the describe embodiment, the Route DN, an indication of the numbering plan type of the originating gateway, a numbering plan index that is for selecting an actual route table, an indication of the address type (e.g., standard or feature) , and, if relevant, the feature type from the Address Translation database. As a part of receiving the response to the query from the Address Translation database, the Call Agent extracts specified data parameters (step 1620). Once the incoming address translation module receives the query response, it transmits select parameters to a route selection module (step 1624) .

FIG. 17 is a flow chart illustrating a method for address translation and call routing according to one embodiment of the present invention. Referring now to FIG. 17, a Route Selection (RS) module receives specified address translation parameters from an Incoming Address Translation module (step 1704). The specified signals include signals that represent the route DN, an index number to the routing tables stored within a routing database, numbering plan type, and, if relevant, feature identification type. Additionally, the RS module further determines a set of corresponding operational parameters including, but not limited too, parameters that define user desired quality of service, maximum cost constraints for a selected route and other such factors (step 1708) .

In one embodiment, the determined set of operational parameters is received from the Incoming Address Translation module. In another embodiment, these operational parameters are stored in a database that is accessed by the RS module. In the described embodiment, these operational parameters are stored in a subscriber feature database. The values of these parameters are a function of subscriber and operator selections. For example, a subscriber may select a desired QoS rating while a network operator may select a maximum communication link cost that can be allocated either to the user or to all calls originating from the originating gateway.

The RS module also transmits a query to the routing database (step 1712) . The query includes the route index number and translated number that was received from the Incoming Address Translation module, user preference of carrier code and quality of service, and operator assigned cost.

After transmitting the query to the RS database, the RS module extracts routing data parameters from the response from the RS database (step 1716) . More specifically, the RS module extracts a route string (ordered list including address of at least one router or routing node, an indication of the terminating network type, and a terminating gateway name (ID) ) . Once the RS module receives the query response, it transmits select routing parameters to the Outgoing Address Translation module (step 1720) .

FIG. 18 is a flow chart illustrating a method for address translation and call routing according to one embodiment of the present invention. Referring now to FIG. 18, a Route Selection (RS) module receives specified routing parameters from a Route Selection module (step 1804). The specified signals include a route string (ordered list including address of at least one router or routing node, an indication of the terminating network type, and a terminating gateway name (ID) . Responsive thereto, the Outgoing Address Translation module generates and transmits a query to an address translation database to obtain the actual routing information (step 1808). The actual routing information is a function of route string, network type, and terminating gateway name (ID). Thus, the query includes these parameters at a minimum in the described embodiment of the invention.

Thereafter, the Outgoing Address Translation module receives a response. From this response, the Outgoing

Address Translation module extracts a translated DN (step

1812) . It then transmits the translated DN to the terminating gateway to enable a complete call connection

(step 1816) .

FIG. 19 is a flow chart illustrating a method for setting up a call through a communication link that includes the Internet according to one embodiment of the present invention. Referring now to FIG. 19, a Call

Agent receives call setup signals from a media gateway

(step 1904). The call setup signals include signals that represent the dialed digits, number type and originating gateway ID. Accordingly, the Call Agent extracts the data from the call set up signal and determines the gateway ID (step 1908) .

In one embodiment, the gateway ID is used to determine location of the gateway wherein the location may be used for determining how to interpret digit entries. In an alternate embodiment, the ID is used to identify a network or operator or other grouping indicator wherein the network, operator or other grouping indicator is used to determine proper digit interpretation. For example, a given operator may well have gateways in different international jurisdictions or even regions (Class 4, for example) that are all formed to operate similarly.

In the described embodiment, the location must be determined at least to an extent that it enables the Call Agent to correctly interpret the intended meaning/result from the sequence of digits. For example, a given feature may have different number feature codes or key sequences that are used to activate the given feature in different geographic areas according to the country, the service provider, etc.

The IAT module also analyzes the dialed digits and number type as a part of interpreting them and determining the user's intended result (step 1912). In general, the Call Agent interprets the dialed digits by evaluating the location of the originating gateway, identifying its calling plan(s) and other similar considerations so that the context of the digits may be understood. By knowing these considerations, digits that represent or define the type of call may be stripped so that the destination number may be determined so that the call may properly be routed to the serving called party gateway.

Thus, the next step is to determine the dial plan name and the numbering plan names (step 1916) . If a gateway device operates a "public" plan, then no access numbers need be dialed to access the "public" networks. On the other hand, if the network is a private network, then it may have anyone of many different access codes that required dialing to reach the public network. On the other hand, if no such access code is dialed, then the Call Agent may determine that the call being requested is for a connection to another phone within the private network.

Similarly, the public and private plans may have similar or different feature codes for the same features and may also have different sets of features. Thus, step 1912 includes determining the type of dial plan and the name of the specific numbering plan under which the originating gateway operates. In the described embodiment, there is a unique routing table that is assigned to each numbering plan. FIG. 3 and FIG. 4 list exemplary relationships between dial plans and numbering plans . Once the dial and numbering plans are known, then the Call Agent determines whether a feature code was selected based upon the dialed digits (step 1920) . If so, the Call Agent determines what feature code was entered and then "strips" the feature code digits (step 1924). By "strip", what is meant is that those digits are removed from further analysis of the called party identity or destination/serving gateway.

Once the dial and numbering plans are known, the Call Agent also determines if a private network access was entered to gain access to the public network if the originating gateway is one that serves a private network

(step 1928) . If so, the Call Agent determines that the call is to be routed to a phone outside of the private network, for example, to a phone coupled to the "public" network as a part of setting up the call. Thereafter, the Call Agent "strips" the access code from the dialed digits as described before.

Additionally, the Call Agent determines whether a national or international prefix was dialed signifying the caller wishes to make a long distance call within the same nation or, respectively, an international call (step 1936) . The Call Agent, if the prefix is an international prefix, determines whether the destination country is one that is supported for international calling and, if so, strips the international prefix digit^'s (step 1940). If a national prefix was dialed, then the Call Agent strips the national prefix digit (s) and adds a country code (step 1944) .

FIG. 20 is a flow chart illustrating one aspect of a method for processing a dialed number according to one embodiment of the present invention. The method of FIG. 20 includes two sets of processing steps according to whether a call is being originated from a private or a public network. The first step, therefore, is to determine the type of network (step 2004). If the call is from a private network, the method includes determining whether a feature has been activated (e.g., call forward unconditional) (step 2008). If so, the feature name is returned for processing (step 2012). If a feature was not activated, then it is determined whether an access code was entered for access to another network such as the public network or another private network (step 2016) . If an access code was entered, then the system gets the plan number, strips the access code, and returns the plan name and a dialed number that is to be used at a destination gateway to connect the call to the called party (step 2020) . If not, the system returns its own plan number and the dialed number.

If, back in step 2004, it is determined that the dial plan is the public dial plan, the system next determines whether a feature was activated (step 2028) .

If so, the feature name is returned (step 2032) . If a feature was not activated, the system next determines whether an international call was dialed (step 2036) . If so, the international prefix is stripped and the plan name is returned (step 2040) . If the call is not an international call, the system then determines whether the call is a long distance call (step 2044) . If the call is a long distance call, the national prefix number is stripped and the country code is added (step 2048) . If the call is not a long distance call, the country code and national dialing codes are added and returned with the plan name (public) (step 2052).

FIG. 21 is a flow chart illustrating another aspect of a method for processing a dialed number according to one embodiment of the present invention. Initially, the system determines whether the dial plan is public or private (step 2104). If it determines the plan is private (step 2108), it returns the same route directory number (step 2112).

If the system determines that the dial plan is public (step 2116), then it determines whether the destination gateway country code is the same as the source (of the media/signaling gateway) (step 2120). If the country code is the same, it next determines whether the area code of the destination gateway is the same as the source (step 2124) . If so, it strips the area code and returns the subscriber number (step 2128). If not, it determines whether the area code in the number is a is listed as a supported area code in a gateway supported area code list (step 2132) . A supported area code is one to which the present system may setup the call. For example, the area code for a remote area may not have a media/signaling gateway to which calls may be routed by way of the Internet. If it is a supported area code, however, the system is formed to route the call to a specified gateway from which the call is originated as a public telephone network call to the called party in Sri- Lanka. If the area code is a supported area code, the national prefix code, area code and subscriber number are generated and returned (step 2136). If the area code is not supported, the "FALSE" is returned meaning the call is rejected (step 2140) .

If it is determined in step 2120 that the country code is not the same as the source, the system determines whether the country code in the number is in a supported country code list of the destination gateway (step 2144). If not, a "FALSE" is returned (step 2140) . If so, the International Prefix Number, country code, area code and subscriber numbers are returned (step 2148).

FIG. 22 is a signal flow diagram that illustrates operation of a telecommunication network for two network calls according to one embodiment of the present invention. An originating phone 2204 generates and "off hook" indication and transmits the dialed digits in a signal 2206 to a media gateway 2208 in an attempt to connect to a destination phone 2242. The media gateway 2208 then generates a setup signal 2210 to the call agent 2212 identifying the end point name. The call agent 2212 then returns a CRCX (create connection, endpoint name) in a signal 2214. The media gateway 2208 then returns an ACK signal in a signal 2216. The signal 2216 includes the IP address of the originating gateway and a port number for the call. This information is referred as SDP1.

The address translation processing described herein then is performed. More specifically, the call agent 2212 performs the incoming address translation, the route selection and the outgoing address translation processing steps. Thereafter, the call agent 2212 generates a CRCX (create connection) signal 2218 that is transmitted to the destination gateway 2220. The CRCX signal 2218 includes the SDP1 data received from the originating media gateway 2208.

The destination gateway then responds with an ACK signal 2222. Signal 2222 includes the destination media gateway ID as well as the port number that is reserved for the incoming call in the described embodiment. The call agent 2212 then responds with a setup signal 2224 that includes a route string from the outgoing address translation processing. The route string includes, in the described embodiment, the destination number.

Thereafter, the destination gateway 2220 responds with an alerting signal 2226 that indicates that it is alerting the called party that a call is being received for it. The call agent 2212, in the described embodiment passes the alerting signal 2228 to the originating gateway 2208. Thereafter, the destination gateway generates a connect signal 2230 that is received and transmitted to the origination gateway in a signal 2232.

The call agent then transmits an MDCX signal 2234 to prompt the originating gateway to not allow any other users to connect to the reserved port identified in SDPl. Thereafter, the call agent receives an ACK signal 2236 from the originating media gateway 2208 and forwards a connect ACK signal 2238 to the destination media gateway 2220. Finally, the call is connected in signal 2240 to destination phone 2242 and originating phone 2204.

The inventive method and apparatus disclosed herein are particularly advantageous in that they provide a capability for a geographically distributed switch having address translation and routing capabilities to be created and implemented instead of the large traditional monolithic switches. The inventive method will also work with traditional monolithic switches.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and detailed description. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the invention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the claims. As may be seen, the described embodiments may be modified in many different ways without departing from the scope or teachings of the invention. For example, any combination of the described methods may be combined to create an inventive system that routes a call from point to point through a plurality of networks in a seamless and backwards compatible manner.

Claims

Claims :

1. A system for routing voice calls and real-time applications through a data packet network, comprising:

a call agent formed to setup a call route for a calling party through the data packet network; and

an address translation module for determining the call route and for delivering a route string to the call agent, the address translation module including logic setting up a call to a called party in any one of a wide variety of destinations including local, regional and international destinations relative to the called party.

2. The system of claim 1 wherein the address translation module includes an incoming address translation module.

3. The system of claim 1 wherein the address translation module includes a route selection module,

4. The system of claim 1 wherein the address translation module includes an outgoing address translation module.

5. The system of claim 1 wherein the address translation module is formed to generate route strings defining a route path that include an Internet portion and public switched telephone network (PSTN) .

6. The system of claim 5 wherein the route string includes dialed digits that are to be used by a destination gateway to create a PSTN connection between it and the called party wherein the call agent sets up an IP connection to the destination gateway.

7. The system of claim 6 wherein the destination gateway includes circuitry to originate calls to called parties.

8. The system of claim 6 wherein the destination gateway is coupled to communicate with a PSTN device for originating calls to called parties according to what dialed digits are received from the destination gateway.

9. An address translation engine, comprising:

an incoming address translation module; a route selection module; and an outgoing address translation module.

10. The address translation engine of claim 9 wherein the incoming address translation module is formed to receive and respond to a dialed number, an originating gateway ID and an indication of the number type.

11. The address translation engine of claim 9 wherein the route selection module is coupled to receive and respond to a route directory number, a carrier code, and a preferred network type.

12. The address translation engine of claim 11 wherein the route selection module also is coupled to receive and respond to a quality of service rating.

13. The address translation engine of claim 11 wherein the route selection module also is coupled to receive and respond to a defined maximum cost amount.

14. The address translation engine of claim 11 wherein the route selection module also is coupled to receive and respond to an index from the address translation module, the index for specifying what route table is to be used by the route selection module.

15. The outgoing address translation engine of claim 9 being formed to receive and respond to a route directory number and a terminating gateway ID wherein the outgoing address translation module produces a translated directory number for delivery to the call agent's processing circuitry.

16. The address translation engine of claim 9 wherein each of the modules are collocated.

17. The address translation engine of claim 9 wherein each of the modules are not collocated and are formed to communicate by way of the Internet.

18. A call agent having circuitry for defining operational logic for an address translation engine, comprising:

logic for determining a call route through a data packet network;

logic for creating a route string that includes the call route to a destination gateway; and

logic for enabling a destination gateway to create a communication link by way of a telephone network to a called party.

19. The call agent of claim 18 wherein the tele- phone network comprises a landline telephone network.

20. The call agent of claim 18 wherein the tele- phone network comprises a wireless telephone network.