Source: https://patents.google.com/patent/EP1483888B1/en
Timestamp: 2020-07-14 04:21:57
Document Index: 469754752

Matched Legal Cases: ['arty 504', 'arty 504', 'arty 510', 'arty 504', 'arty 504', 'arty 504']

EP1483888B1 - Apparatus and method for computer telephone integration in packet switched telephone networks - Google Patents
EP1483888B1
EP1483888B1 EP03705780.9A EP03705780A EP1483888B1 EP 1483888 B1 EP1483888 B1 EP 1483888B1 EP 03705780 A EP03705780 A EP 03705780A EP 1483888 B1 EP1483888 B1 EP 1483888B1
EP03705780.9A
EP1483888A1 (en
1993-07-16 Priority to US92832 priority Critical
2002-03-07 Priority to US10/092,832 priority patent/US6856618B2/en
2002-05-15 Priority to US145998 priority
2003-01-15 Priority to PCT/US2003/001197 priority patent/WO2003077522A1/en
2004-12-08 Publication of EP1483888A1 publication Critical patent/EP1483888A1/en
2013-04-17 Publication of EP1483888B1 publication Critical patent/EP1483888B1/en
A second protocol for performing packet telephony control functions is the Session Initiation Protocol (SIP) defined by IETF RFC 2543. Like H.323, SIP includes a plurality of functions that establish, modify and terminate multimedia sessions. The SIP methodologies include a variety of functions that go beyond those described by H.323. For example, SIP includes the ability to support mobile users, the use of standardized HTTP syntax and URLs, the ability to have multiple SIP connections through a single TCP/IP session, the use of "proxy servers" (defined further below) and a variety of other robust features discussed in more detail below.
United States Patent No. 6,201,805 ("the 805 patent"), from which the present application descends, is directed to an H.323 or other packet telephony system in which an applications computer is connected to a Gatekeeper for performing basic call monitoring and control functions. Although the '805 patent and some further pending related applications greatly improve the capabilities of packet telephony systems utilizing CTI, no known prior art can provide routing flexibility in such CTI systems.
WO 00/79756 A2 describes a system for providing Value-Added Services (VAS) in a telecommunications system having a packet-switched network portion (PSN) operable with Session Initiation Protocol (SIP). The integrated telecommunications network includes a SIPext SSP server, a trigger server, and a service node having a Service Logic Program that is operable with Intelligent Network Application Protocol (INAP). The SIPext SSP and service nodes are provided with the capability to communicate using SIP-compliant messaging. New header fields are provided that specify operations to be performed by the service node with respect to a service. INAP service parametric data is also provided in the header fields in a sequential form. When a call is received in the SIPext SSP server for a user having a subsription for a VAS, it queries the user profile stored in the trigger server. If the user is subscribed for a service, a SIP request message is formulated based on the user profile, wherein appropriate headers are populated with relevant parametric information and call context data. The service node launches the SLP based on the information provided in the request message and sends a SIP response message to the SIPext SSP server with an instruction concerning the provisioning of the VAS. The SIPext SSP server, thereafter, takes an appropriate action based on the response message and any parametric information contained therein.
Figure 1 shows a conceptual overview of an exemplary embodiment of the present invention as incorporated into a packet network telephony system;
Figure 2 shows exemplary message flow between system elements during the establishment of an inbound call that is detected by an external software application using the packet network telephony system as enhanced and extended by the present invention, and the H.323 protocol;
Figure 3 shows an exemplary message flow diagram utilizing the invention to establish an outbound call requested by an external software application in a similar environment;
Figure 4 shows a signal diagram of a direct connection from a calling terminal to a called terminal using the Session Initiation Protocol (SIP);
Figure 5 shows two different embodiments of an SIP implementation in a network;
Figure 6 shows a signal diagram using proxy servers and the SIP protocol;
Figure 7 depicts a computer telephony integration (CTI) applications computer interfacing with a network implementing SIP;
Figure 8 shows another signal diagram for an exemplary embodiment of the invention;
Figure 9 shows a flowchart of a method for implementing call routing in accordance with an exemplary embodiment of the present invention; and
Figure 10 is a flow chart of an exemplary implementation of the present invention.
A technical advance is achieved in accordance with the present invention that relates to a packet network telephony call processing device (e.g.; an H.323 gatekeeper, a SIP proxy server, and/or a "pass-through" server) that is arranged to interface with a plurality of external call processing applications programs that may be located on one or more remote computers. Regardless of the protocol utilized, we term herein as the CTI interface the server or computer and associated software that interfaces to the third party applications computer from the packet telephony environment. As explained below, in a SIP situation, this CTI interface may be, for example, the proxy server or "pass through" server, and in the H.323 environment, such CTI interface is preferably the gatekeeper.
In a still further enhanced embodiment of the present invention, the applications computer is utilized to perform call routing services. More specifically, and utilizing the H.323 gatekeeper example for purposes of explanation only, calls may arrive at the gatekeeper to be completed to a "virtual" called party, or "virtual" number. The term virtual number as used herein means a called number that does not correspond to a called terminal, but which will be translated to one or more actual called numbers corresponding to physical terminals by an applications computer.
Figure 1 illustrates an overview of the interconnection of the gatekeeper computer 102 with the applications computer 103 according to the teachings of the present invention and utilizing the H.323 standards and terminology. To enable such interconnection, gatekeeper computer 102 is enhanced and extended by the addition of software whose functions are described below. Communications path 105 may be any type of data communications path.
The arrangement of Figure 1 includes several external telephony applications systems 104, typically implemented as software, which may be located on applications computer 103 or on separate computers connected via any communications network to applications computer 103. Typically, the applications computer may be collocated with one of the end points described below.
The arrangement of Figure 1 also includes end points 106, which may be personal computers, network computer devices (NCs), or any other node capable of interconnection to the packet network telephony environment.
Figure 2 shows an exemplary message flow diagram for detecting an inbound call from a remote end point (e.g., terminal) to a local end point supervised by an external computer telephony application using the present invention. The specific example shown in Figure 2 is the monitoring of an incoming call to end point 202 using packet network telephony methods and apparatus as described in the H.323 standard, enhanced by the present invention to permit the participation of an external software application 201. End points 202 and 204 represent audio terminals, for example, computer systems equipped as H.323 compliant telephone devices. Gatekeeper 203 is as described, for example, in the H.323 standard and as further enhanced by the present invention, and the external application 201 may be present on a separate computer as previously discussed.
Figures 3a and b show another example of an external call processing application requesting the establishment of an outbound call from initiating end point 386 to receiving end point 390. Many of the messages involved in this operation are substantially similar to those previously set forth with respect to the monitoring of the inbound call described in Figure 2. New messages not previously discussed in Figure 2 are described below. As with the discussion of Figure 2, the external application 392 in Figures 3a and 3b is assumed to have previously communicated with gatekeeper 388 in accordance with other methods described by this invention to indicate its intention to issue call control requests with respect to initiating end point 386.
In Figures 3a and 3b, gatekeeper 388 also includes the conference control point function as currently known to the packet network telephony art. This function is used by the invention to interconnect two call segments, namely the segment between the initiating end point 386 and the conference control point; and between the conference control point and the receiving end point 390. For clarity of description, the combined gatekeeper and conference control point apparatus is referred to as "gatekeeper 388."
Next, the gatekeeper 388 sends a new message 304 to external application 392 to alert it that the call request has been received and is being processed. Much of the remaining signaling, relating to the establishment of that segment of the call between initiating end point 386 and gatekeeper 388 in Figures 3a and 3b, is substantially similar to that previously described with respect to Figure 2 and thus will not be repeated. Similarly, once the first leg of the call has been set up, gatekeeper 388 proceeds in similar fashion to set up the second leg of the call from itself to receiving end point 390.
However, during the process depicted in Figures 3a and 3b, gatekeeper 388 sends new messages to the external application 392 at relevant stages of call processing, including:
5. Any other messages relating to exceptions, status, or control. The application systems 104 may then provide monitoring and control as desired, and as described in the parent application, now U.S. Patent No. 6,201,805 . Thus, the system provides for monitoring and control of H.323 calls.
Moreover, as described more fully below with respect to Figure 9, the gatekeeper 388 may receive virtual numbers that are conveyed to an applications computer for translation to actual numbers.
Figure 4 shows an alternative embodiment of the present invention utilizing the Session Initiation Protocol (SIP) in place of H.323. In SIP, callers and callees can establish calls in one of three manners; (1), the caller directly contacts the callee, as shown in Figure 4; (2), the caller contacts the callee through a proxy server, as shown in Figure 5A; or (3) the caller contacts the callee through a re-direct server shown in Figure 5B. As will be explained further below, the signaling sequence for the three methodologies is very similar, except that the information required to contact the callee is derived from different sources for the three different cases.
More specifically, in the direct contact of Figure 4, the caller is aware that the SIP Universal Resource Location ("URL") of the callee maps to a specific known Internet protocol ("IP") address. In the arrangement on Figure 5A, the caller is not aware of the IP address of the callee. Therefore, the caller 502 sends a request to the proxy server 503 to call the desired SIP URL of the called party, and proxy server 503 translates the SIP URL to the IP address of called party 504. The proxy server 503 then forwards the request over a data network to the called party 504.
Finally, the use of a re-direct server 506 allows the SIP URL to be translated by redirect server 506, but rather than transmit the request to the called user as in the case of the proxy server in Figure 5A, the translated address is returned back to the caller 509 for a direct connection through appropriate servers to called party 510.
In the Figure 5A example of a proxy server, the exemplary called terminal's SIP URL could be, for example, Joe@acme.com, and the proxy server would translate that address to the appropriate top-level SIP server for the acme.com domain into a more standardized Internet address, such as 33.65.43.85. The standardized address is then used to route the data through the network utilizing standardized protocols such as TCP/IP and the like.
Of the three types of SIP calls described, the least common would be that of Figure 4. Normally the caller will not have the appropriate IP address for the called party and would require the translation services of a server. While most systems would normally operate utilizing either a proxy server 503 or redirect server 506, for purposes of explanation herein, and not by way of limitation, we utilize the example of Figure 5A wherein a proxy server 503 is implemented.
Referring to Figure 5A, when an SIP client 502 attempts to initiate a call, it sends an SIP Invite message to proxy server 503 specifying the SIP URL of the desired called party 504. The proxy server 503 must initiate the task of resolving this SIP URL to the IP address of called party 504. The proxy server may use the standardized domain name system to resolve such address, or any other resolution scheme desired. Additionally, at the stage in call processing where proxy server 503 receives the Invite message from caller 502, any policy management desired may be applied. For example, proxy server may read the calling terminal identification ("ID") to ensure that the caller is authorized to make the call, that the appropriate network bandwidth is available, that any reporting, or logging of information takes place, etc.
After any such initial local processing by proxy server 503, proxy server 503 translates the desired called party name into an address and forwards the resolved address with the request through one or more further servers 505 to called party 504. The sequence is shown more clearly in Figure 6. The invite message 601 is received from the outbound proxy and forwarded through one or more servers to ultimately reach the called party terminal. The vertical line 602 represents the domain acme to which the request is forwarded, and the vertical line 603 represents the subdomain, which ultimately forwards the request to the called terminal. For example, vertical line 602 may represent the domain name acme.com, and vertical line 603 would represent the sales department, or subdomain, sales.acme.com.
In response to receiving the Invite message, the SIP OK return message is forwarded back through the same path substantially as previously described with respect to the direct connection of Figure 4. Next, as shown, the ACK message gets sent from calling terminal 503 to the called terminal 504 again as previously described. It is noted that as the call set up messages are exchanged between the caller and called party, messages may follow the same path, or they follow different paths through different servers. SIP includes appropriate commands to force use of the same path, as discussed further below.
In accordance with the teachings of the present invention, it is desirable to insert into the arrangement of Figure 5A a system which can utilize Computer Telephony Integration (CTI) applications to monitor and control calls by connecting into the system. Since the proxy server 503 is also likely to handle call requests attempting to call terminal 502 (i.e., when the calling party in the previous example is later the called party) it appears initially that all information regarding inbound and outbound calls would traverse proxy server 503, and thus, the proxy server 503 is the appropriate place in the system to interface the applications computer previously discussed. That is, the CTI interface should be the proxy server 503, which gets connected to the applications computer. However, several issues arise:
One possible architecture for interfacing an applications computer with an SIP proxy is depicted logically in Figures 7 and 8. A new entity termed a pass through proxy 801 is depicted. The pass through proxy is software which may physically run on proxy server 503 but which is interposed logically between the software, which would otherwise be resident on proxy server 503 in a SIP environment without CTI, and terminal 502. Alternatively, the pass through proxy 801 may be a separate device interposed logically and physically between proxy server 503 and terminal 502. In Figure 7, we show an example of the latter, which we shall utilize for explanation purposes herein.
Assuming a single pass through proxy 801 is associated with each proxy server, recording each Register request results in a list of terminals that constitute the entire domain for which the pass through proxy 801 would be responsible. In other words, the Register list in pass through proxy 801 represents some subset of that known to proxy server 503 of Figure 7.
Similarly, when an Invite message is received, the pass through proxy adds a header to the request and then forwards it to the SIP proxy 503. The "Via" header, part of the known SIP protocol, should be used for this purpose. The additional header added upon the first message for a specific call being set up from a calling terminal 502 causes subsequent result/acknowledgement messages to be transmitted through the pass through proxy 801. Such system provides that for all outbound call set up messages, any status and control information required to be monitored by applications computer 701 will be transferred through pass through proxy 801. This provides a full view of the outbound call set up, acknowledgement messages at the pass through proxy 801, and thus, to the applications computer 701 that interfaces to pass through proxy 801. Moreover, such a solution does not require rewriting of normal SIP proxy software, since the pass through proxy hardware and/or software may be implemented entirely separately from the SIP proxy server.
Otherwise, as shown in Figure 7, application computer 701 cannot monitor or control such call. The solution to this problem is similar to the previous solution. When a terminal is registered with any proxy server in the entire system, a special header is added to its contact address. The "maddr" header in the SIP protocol should be used for this purpose. The header affects the address translation process when other proxy servers associated with calling terminals attempt to contact the particular called terminal associated with the subject address.
More specifically, this header instructs proxy server 503 to redirect all inbound call setup requests addressed to that contact address to the address specified in the "maddr" header.
The previously defined solutions cause all inbound and outbound call signaling to be transmitted through the proxy server 503 and pass through proxy 801. As shown in Figure 7, since the applications computer 701 interfaces to pass through server 801, there is now full access to all call data, and the system has not altered the proxy server 503 in any substantial way as to cause rewriting of the software or even reconfiguration of the proxy server 503.
While the above technique insures that pass through proxy 801 has access to call setup messages for inbound and outbound calls, the headers may also require that all messages concerning the call (e.g. hold/retrieve, call hang-up, etc.) are transmitted through the pass through proxy. In general, the pass through proxy 801 and/or proxy server 503, utilizing the techniques of the present invention, add headers to insure that the functions desired to be monitored and controlled pass through the separate logical portion of the system that monitors and controls those functions. The "record-route" header should be utilized to ensure that all control messages after call setup (e.g. disconnect) are routed through the pass through proxy. This header should be added to call-setup messages as they pass through 801. It should be noted that the pass through proxy 802 should not be a redirect server, as this would not receive call signaling messages for monitored and controlled calls after call setup.
The final issue that needs to be addressed is the ability of the application computer 701 to initiate calls. The issue is solved by having the applications computer 701 indicate to the pass through server that it should signal the calling terminal 502 as if it were receiving an inbound call from the pass through server. This "fake" inbound call is intended to prepare the calling terminal 502 to enter a state where it can listen to (an as yet undefined) media stream to be set up in a subsequent outbound call to the called terminal 504, described below.
In another enhanced embodiment, the point-to-point call shown in Figure 5 is replaced with a conference call wherein information may be shared among three or more terminals. Such Internet conferencing methods require that the servers conveying the media stream after call set up simply duplicate messages and transmit them to two or more different addresses. End users then have control over exiting or entering conferences by entering specified codes and passwords, in accordance with known techniques.
If the application computer supplies further routing information within a configured time period, this information is used to resume call processing and routing of the call to the specified destination or possibly another virtual destination. If no further information is provided by the application computer within the time period, the pass through server should provide some default routing for the call. Figure 10 shows the typical flow of messages for the SIP environment, and is described in further detail later herein.
Figure 9 depicts a flow chart of how an applications computer 701 would interface with an appropriate CTI interface for implementing an exemplary embodiment of the present invention. It is noted that the flow chart of Figure 9 does not represent any specific protocol, and that the protocol for implementing the flow chart of Figure 9 may be SIP, H.323, or any other protocol, and may utilize a variety of message exchange scenarios between an applications computer and a CTI interface.
a proxy server (503) to receive and store a first table for address translation and registration of plural terminals (502, 504) associated therewith, each terminal being capable of participating in a telephone call to be implemented over a packet switching data network, said proxy server being connected to a data network;
a pass through server (801) connected to said data network and interposed between a terminal initiating a call and said proxy server (503) and through which information between said proxy server and any of said terminals passes, said pass through server including a second table that mirrors said first table, said pass through server (801) configured to add a header to a first message for said call to cause subsequent messages for said call to be transmitted through the pass through server (801);
said pass through server (801) also being configured to communicate information to and from an applications computer (701), said applications computer including software to at least control or monitor calls among said terminals over said data network, said applications computer and said pass through server exchanging routing information to enable the translation of a virtual number received from a calling party to one or more physical numbers representing called parties.
The system of claim 1 wherein said proxy server (503) and said pass through server (801) are resident on the same hardware platform.
The system of claim 1 wherein said proxy server (503) is arranged to receive an address in a first form from one of said terminals (502, 504), translate said address into a second form, and send said address in said second form to a second server.
The system of claim 1 wherein said proxy server (503) is arranged to receive an address in a first form from one of said terminals (502, 504), translate said address into a second form, and return said address in said second form to said terminal from which said address in said first form was received, and wherein said second form of address is a virtual address to be later translated by a second proxy server into one or more actual addresses
The system of claim 4 wherein said second server is arranged to communicate with an applications computer to translate said address in said second form to one or more different addresses.
The system of claim 5 wherein multiple SIP sessions are contained within a single TCP/IP session, and wherein said proxy server (503) or said pass through server (801) is arranged to distinguish among said multiple SIP sessions.
The system of claim 5 wherein said proxy server (503) or said pass through server (801) includes software to determine whether a particular call is authorized prior to completing said particular call.
The system of claim 7 wherein said proxy server (503) or said pass through server (801) contains software to implement multiparty conferences.
transmitting a call initiation message to a proxy server (503) or a pass through server (801);
in response to receipt of said call initiation message, transmitting from said pass through server or said proxy server a fake inbound call message to a calling terminal (502, 504) specified in said call initiation message; and
in response to said fake inbound call message, initiating an Internet telephone call from said calling terminal, said phone call being initiated to a virtual number that does not correspond to an actual called terminal unless and until translated by an applications computer (701).
The method of claim 9 further comprising each of plural calling terminals (502, 504) registering with said proxy server (503) and said pass through server (801).
The method of claim 10 wherein said initiating an Internet telephone call includes transmitting an Invite message of the Session Initiation Protocol SIP through a pass through server (801) and a proxy server (503).
The method of claim 11 wherein said pass through server (801) or said proxy server (503) translate a called terminal address from a first form to a second form and transmit said address back to said calling terminal (502, 504) or to a separate server, and wherein said separate server communicates with the applications computer (701) to translate a virtual number to an actual called number corresponding to a called terminal.
The method of claim 12 wherein said pass through server (801) communicates with a Computer Telephony Integration CTI applications computer.
The method of claim 13 further comprising issuing instructions from said applications computer (701) to instruct said pass through server (801) to monitor or control a call with specified parameters.
The method of claim 14 further comprising issuing a disabling command to cease specified monitoring and control functions at specified times.
A data medium having stored thereon computer product code adapted to perform all the steps of any one of claims 9 to 15 when said program code is run on a computer.
EP03705780.9A 1997-10-21 2003-01-15 Apparatus and method for computer telephone integration in packet switched telephone networks Active EP1483888B1 (en)
US92832 1993-07-16
US145998 2002-05-15
EP1483888A1 EP1483888A1 (en) 2004-12-08
EP1483888B1 true EP1483888B1 (en) 2013-04-17
EP03705780.9A Active EP1483888B1 (en) 1997-10-21 2003-01-15 Apparatus and method for computer telephone integration in packet switched telephone networks
CN101808304A (en) * 2009-06-05 2010-08-18 韩燕� Communication method of multiple-number telephone
CN101827465A (en) * 2009-06-05 2010-09-08 韩燕� Multi-number telephone terminal
RU2570899C2 (en) * 2011-06-30 2015-12-20 Уолд Эмердженси Нетворк-Невада, Ллд. Attaching multiple telephone lines to single mobile or landline telephone
AU2915901A (en) 2000-02-08 2001-08-20 Syndeo Corp Method and apparatus for diverting a packet-switched session utilizing an intelligent proxy agent
TWI229518B (en) 2005-03-11
Ref document number: 1070511
Ipc: H04M 7/00 20060101AFI20130307BHEP
Ipc: H04L 29/06 20060101ALI20130307BHEP
Ipc: H04L 12/931 20130101ALI20130307BHEP
Ref document number: 607904
Ref document number: 60343797