Method and system for redirecting calls

The present invention relates in general to call redirection and, in particular, to a method and system for using a lightweight directory access protocol (LDAP) to redirect calls.

Conventionally, calls placed in the Public Switched Telephone Network (PSTN) require offboard lookups to redirect the call to the correct destination. For example, when a caller makes an 800 or 888 long-distance call, wherein a service access code (SAC) is translated into a directory number, or when a caller makes a local number portability (LNP) call, wherein a local routing number is used alongside the original directory number to route the call to its destination, a Signaling System 7 (SS7) Transaction Capabilities Application Part (TCAP) stack performs the necessary query from the switch to an offboard signaling transfer point (STP) and Signaling Control Point (SCP). Such SAC or LNP queries may also be performed using proprietary data protocols such as an X.25 network, or the like.

A drawback with using the SS7/TCAP stack, together with the STP and SCP, to perform SAC and/or LNP queries is that 30-40% more time is consumed routing redirected calls than is consumed routing non-redirected calls. This causes more blockage of telephone lines, and reduces the traffic capacity of telephone switches. SS7/TCAP stack systems are also relatively expensive. Accordingly, a continuing search has been directed to the development of methods and systems which can be used to perform SAC and/or LNP queries and to redirect calls more quickly and cost-effectively than is possible using a SS7/TCAP stack, SCP, and STP combination.

According to the present invention, SAC and/or LNP queries and the redirecting of calls is improved by using a TCP/IP stack and LDAP protocol in lieu of an SS7/TCAP stack, SCP, and STP. This permits the use of internet protocols which are less expensive and faster than an SS7/TCAP stack, SCP, and STP, thereby reducing telephone line blockage and increasing the traffic capacity of telephone switches.

For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a schematic diagram of a system configured for redirecting calls in accordance with the prior art;

FIG. 2 is a schematic diagram of a system configured for redirecting calls in accordance with the present invention; and

FIG. 3 is a flow chart illustrating control logic for implementing the system shown in FIG. 2 .

Referring to FIG. 1 of the drawings, the reference numeral 10 generally designates a switching system configured in accordance with the prior art. The system 10 includes a calling telephone 12 and a called telephone 14 interconnected via a switch service point (SSP) 16 . The SSP 16 includes service access codes (SAC, e.g., 800 and 888 numbers) application 17 a , and a local number portability (LNP) application 17 b , for processing, respectively, SAC and LNP calls. The SSP 16 , further includes a transaction capabilities application part (TCAP) function 18 effective for performing database queries for the SAC and LNP applications 17 a and 17 b . The TCAP function 18 is connected for routing queries, and for receiving responses, via a signaling system 7 (SS7) stack 19 a , an SS7 network 19 b , and any service transfer points (STP's) 22 in that network, to and from, respectively, a service control point (SCP) 24 .

In operation, when a SAC call is made, the SSP 16 receives a SAC number from the calling telephone 12 . The SAC application 17 a within the SSP uses the TCAP function 18 to generate from the SAC number a query which is communicated via the SS7 stack 19 a , the SS7network 19 b , and the STP 22 to the SCP 24 . The SCP 24 then translates the SAC number to a directory number (DN). The DN is returned in a response message from the SCP 24 via the STP 22 , the SS7 network 19 b , and the SS7 stack 19 a , to the SAC application 17 a . The SAC application 17 a causes the SSP 16 to route the call to the DN, that is, to the called telephone 14 , in a manner well-known in the art. Other configurations of SAC service exist in which a local exchange carrier (LEC, not shown) switch uses the SCP only to determine the interexchange carrier servicing the SAC number, and then to route the call to that carrier, which carrier in turn performs the SCP translation mentioned above.

Alternatively, if the LNP application 17 b on the SSP 16 detects a number which may have been ported, in a manner well-known to the art, the LNP application 17 b performs a query in a similar manner as described above for the SAC application 17 a , except that the message encoded via TCAP may be different, and the query may be routed to a different SCP 24 than that used for SAC numbers. In that case, the SCP 24 returns a location routing number (LRN) if the called number has been ported, which the SSP 16 uses to route the call to the called telephone 14 , in a manner well-known to the art.

The system 10 and the operation of the system 10 are considered to be well-known to those skilled in the art and will therefore not be described in further detail.

When a call is redirected (e.g., using the SAC or LNP applications 17 a and 17 b , respectively) in accordance with the prior art system 10 shown in FIG. 1, the SSP incurs about 30-40% more overhead on the call than it would with an ordinary (e.g., other than SAC or LNP) call. As a result, the SSP can process fewer calls, more calls may be blocked, and the revenue earned by the operator of the SSP may be reduced. This is due to the overhead incurred by the use of TCAP-based protocols and the SS7 stack and network, which require complex message encoding and other forms of overhead. Although this overhead may vary slightly from implementation to implementation, it is built into TCAP and SS7as a result of the design of these standards-based protocols.

In FIG. 2, an embodiment of the present invention is shown which permits queries to be made with less overhead, which in turn allows calls to be redirected more efficiently than is possible with the prior art system 10 shown in FIG. 1 . The embodiment shown in FIG. 2 is designated by the reference number 30 , and comprises a modification of the system 10 in which the TCAP and SS7stacks 18 and 19 a , respectively, are replaced by a lightweight directory access protocol (LDAP) 31 and a transmission control protocol/ Internet protocol (TCP/IP) stack 32 . The TCP/IP stack 32 is effective for communicating over an IP network 33 , such as, for example, local area networking (LAN) and wide area networking (WAN) technologies such as Ethernet, frame relay, asynchronous transfer mode (ATM), and the like. A DNS server 35 may optionally be used in conjunction with the IP network 33 to facilitate addressing. The TCP/IP stack 32 and the DNS server 35 are considered to be well-known Internet protocols and not to warrant further discussion. The SAC and LNP applications 17 a and 17 b , respectively, use the LDAP function 31 to generate a query which is sent over the IP network to an LDAP server 36 . The LDAP server 36 uses a standard internet protocol and is considered to be a well-known IP-based service, and is discussed in greater detail, for example, in LDAP: Programming Directory - Enabled Applications with Lightweight Directory Access Protocol by Timothy A. Howes and Mark C. Smith, published by MacMillan Technical Publishing, which is incorporated in its entirety herein by reference.

FIG. 3 is a flow chart illustrating control logic for implementing the foregoing system shown in FIG. 2 . As depicted in FIG. 3, in step 50 , the SSP receives a SAC number from the calling telephone 12 and invokes the SAC application 17 a . In step 52 , the SAC application 17 a uses the LDAP function 31 to generate an LDAP query to be sent to the LDAP server 36 . In step 54 , a determination is made whether the LDAP query includes an IP address of the LDAP server 36 to which the query will be sent. If, in step 54 , it is determined that the LDAP query includes an IP address of the LDAP server 36 , then execution proceeds to step 56 ; otherwise, if the query includes a domain name address, execution proceeds to step 58 in which the DNS server 35 is queried to resolve the IP address of the LDAP server 36 .

In step 56 , the LDAP query is transmitted via the LDAP function 31 , the TCP/IP stack 32 , and IP network 33 to the LDAP server 36 . In step 60 , a response, including a directory number (DN), is returned from the LDAP server 36 to the SAC application, again via the IP network 33 , TCP/IP stack 32 , and the LDAP function 31 . In step 62 , the SSP 16 then uses the information, including the DN, to route the call from the calling telephone 12 to the called telephone 14 .

Alternatively, if an LNP number rather than a SAC number is entered from the calling telephone 12 , then the LNP application 17 b , rather than the SAC application 17 a , is invoked. The LNP application 17 b then uses the LDAP function 31 to generate an LDAP query to be sent to the LDAP server 36 . Operation of the system 30 then continues as discussed above with respect to steps 54 - 62 depicted in FIG. 3, wherein the LNP application 17 b is used in lieu of the SAC application 17 a.

By the use of the foregoing system 30 shown in FIG. 3, SAC and LNP functions may be performed more efficiently due to the built-in efficiencies of the Internet protocols used, and the lower cost of equipment designed for IP-based networks as opposed to SS7 networks, particularly in the use of open, commercial technology.

It is understood that the present invention can take many forms and embodiments. Accordingly, several variations may be made in the foregoing without departing from the spirit or the scope of the invention. For example, the present invention may be configured for use with cellular telephones. To further exemplify, both the system 10 and the system 30 may be combined, e.g., used together in a system where both the system 10 of the prior art and the system 30 of the present invention are implemented and used side-by-side.

Although the invention has been described with reference to a specific embodiment, these descriptions are not meant to be construed in a limiting sense. Various modifications of the disclosed embodiments, as well as alternative embodiments of the invention will become apparent to persons skilled in the art upon reference to the description of the invention. It is therefore contemplated that the claims will cover any such modifications or embodiments that fall within the true scope and spirit of the invention.