Apparatus and method for interfacing packet-based phone services with emergency call centers

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to the field of electronic communications, more particularly to inter-working electronic media that operate under disparate protocols, and most particularly to improving access to emergency call centers from phone services that employ networks, such as the Internet, for packet-based data transmission.

2. Description of the Prior Art

In many parts of the world, a three-digit emergency telephone number, such as 911 in the United States and Canada, can be dialed to access emergency services from any telephone connected to a Public Switched Telephone Network (PSTN). <figref idref="DRAWINGS">FIG. 1</figref> illustrates a common system arrangement for a Public Safety Answering Point (PSAP) <b>100</b> for receiving emergency calls and dispatching emergency services. The PSAP <b>100</b> includes a controller <b>102</b> and a terminal <b>104</b>. The controller <b>102</b>, which is a phone system much like a standard Private Branch Exchange (PBX) system, is connected to both a network of selective routers <b>106</b> that direct in-coming calls to the PSAP <b>100</b>, and to a database <b>108</b> that stores information associated with telephone numbers.

In operation, when a caller dials an emergency telephone number, the call is routed to the network of selective routers <b>106</b> that determines the appropriate PSAP <b>100</b> for the call. In some instances, the call may be routed between several selective routers <b>106</b> in the network before being connected to the appropriate PSAP <b>100</b>. Such further routing can occur, for example, when the first selective router <b>106</b> is too busy to handle the call. The call is then routed to the controller <b>102</b> of the PSAP <b>100</b> over a voice trunk according to a telephony protocol such as Centralized Automatic Message Accounting (CAMA) or Basic Rate Interface (BRI). The controller <b>102</b> then directs the call to an available terminal <b>104</b> to be answered by a call taker.

It should be noted that each time a phone number is transmitted from one selective router <b>106</b> to another, or from a selective router <b>106</b> to the controller <b>102</b>, each digit is sent in series and each digit can take upwards of 100 milliseconds in the case of a voice trunk using a CAMA protocol. Accordingly, the caller may experience a delay on the order of 15 seconds before being connected to the PSAP <b>100</b>. This delay is usually accompanied by complete silence on the line, and accordingly, callers sometimes abandon their calls believing that the system is not functioning. The controller <b>102</b> is also connected to a database <b>108</b>, typically by a serial interface such as an RS-232 type of link. The database <b>108</b>, which can be a location database such as an Automatic Location Identification (ALI) database, associates telephone numbers with information, such as street addresses and jurisdictional districts for police, medical, and fire response authorities. Upon receiving a call, the controller <b>102</b> queries the database <b>108</b> for any records associated with the phone number from which the call is being made. The controller <b>102</b> then forwards the records to the terminal <b>104</b> where the records are displayed to the call taker. Querying the database <b>108</b> and transmitting the record to the terminal <b>104</b> can also incur a delay of 10 to 15 seconds.

The database <b>108</b> is based on an assumption that phone numbers are associated with telephones at fixed locations. Recently, the emergence of mobile phone systems has complicated the process of directing emergency calls to the correct PSAP <b>100</b> and providing accurate records to call takers. For mobile phones, triangulation from multiple cell phone towers can often provide at least location information necessary to direct an emergency call to the correct PSAP <b>100</b>. However, phone services through networks, such as the Internet, that employ packet-based data transmission present a further dilemma. A user of such a phone system may be anywhere in the world where a network connection is available. Accordingly, few network phone service providers offer an emergency telephone number service.

<figref idref="DRAWINGS">FIG. 1</figref> further illustrates how some network phone service providers presently offer an emergency telephone number service. When a user dials the emergency telephone number the service provider recognizes the emergency telephone number and accesses a look-up table that correlates the user's phone number with a phone number for an administrative line into a PSAP <b>100</b>. The call is then directed across a packet-based network <b>120</b> to that administrative phone number through a gateway <b>122</b> to a PSTN <b>124</b>. The gateway <b>122</b> provides a conversion from a packet-based network protocol to an analog telephony protocol appropriate for the PSTN <b>124</b>. The PSTN <b>124</b> then directs the call to a phone system <b>126</b> associated with the phone number of the administrative line. The phone system <b>126</b> can be, for example, a PBX system. The phone system <b>126</b> rings a phone <b>128</b> in the PSAP <b>100</b>. In this way the user is connected to a phone <b>128</b> at the PSAP <b>100</b>. Unfortunately, since the phone <b>128</b> is outside of the established system for receiving emergency calls, there is no assurance that the call will be answered, or if answered, will be answered by a trained emergency call taker or appropriately prioritized. Also, no facility exists to query the database <b>108</b> since the call did not come through the controller <b>102</b>, and generally a callback number cannot be displayed.

Therefore, what is needed is a way to route emergency calls made through phone services that employ packet-based data transmission networks to the existing infrastructure of emergency call centers.

SUMMARY

A gateway device for a PSAP comprises a packet I/O interface for communicating with a packet-based network and a telephony IVO interface for communicating with a controller of the PSAP. The gateway device also comprises packet protocol stacks for handling data packets, a TDM/Telephony signaling module for generating telephone signaling information and handling analog or digital voice data, and an auxiliary information gateway application. The auxiliary information gateway application is configured to use the packet protocol stacks and the TDM/Telephony signaling module to parse call session set-up information from a request packet and generate telephone signaling information therefrom. Further, the auxiliary information gateway application is configured to convert analog or digital voice data to packetized voice data and direct the packetized voice data to the packet I/O interface, and convert packetized voice data to analog or digital voice data and direct the analog or digital voice data to the telephony I/O interface. Accordingly, the gateway device allows a call session to be set up and for a voice data channel to be established between a calling party using a telephone that sends and receives voice data in a packet-based protocol and the controller that sends and receives voice data using a telephony protocol. In some of these embodiments, the auxiliary information gateway application is further configured to use the packet protocol stacks to convert packetized data between packet-based protocols.

In some embodiments, the gateway device further comprises database protocol stacks, and the auxiliary information gateway application is further configured to use the packet protocol stacks and the database protocol stacks to parse location information from the request packet and provide the location information as a location database record to a database I/O interface. In other embodiments, the gateway device further comprises a database I/O interface for communicating with a location database and database protocol stacks for handling location database records. In some of these embodiments, the auxiliary information gateway application is further configured to parse a telephone number from the call session set-up information and send the telephone number to the database I/O interface. Also in some embodiments, the auxiliary information gateway application is further configured to receive a location database record from the database I/O interface, use the packet protocol stacks and the database protocol stacks to packetize the location database record, and direct the packetized location database record to the packet I/O interface.

A controller for a PSAP is also provided that comprises the functionality of the gateway device. The controller comprises a packet I/O interface for communicating with a packet-based network, a telephony I/O interface for communicating with a PSTN, packet protocol stacks for handling data packets, a TDM/Telephony signaling module for generating telephone signaling information and handling analog or digital voice data, and an auxiliary information gateway application. The auxiliary information gateway application is configured to use the packet protocol stacks and the TDM/Telephony signaling module to parse call session set-up information from a request packet and generate telephone signaling information therefrom, convert analog or digital voice data to packetized voice data, direct the packetized voice data to the packet I/O interface, convert packetized voice data to analog or digital voice data, and direct the analog or digital voice data to the telephony I/O interface.

A method for enabling an emergency call comprises receiving a request packet from a calling party, parsing call session set-up information from the request packet, and generating telephone signaling information, including a telephone number of the calling party, from the call session set-up information. The method further comprises sending the telephone signaling information to a controller, establishing a voice data channel through the controller, querying a database using the telephone number, and providing a database record to the controller. In some embodiments, the method can further comprise parsing auxiliary information from the request packet, and in some of these embodiments the method can further comprise buffering the auxiliary information. Also in some embodiments, the method can further comprise sending the auxiliary information to the controller, and in some of these embodiments the method can further comprise converting the auxiliary information from a packet-based protocol into another protocol. In some embodiments, the auxiliary information comprises location information.

Another method for enabling an emergency call comprises receiving telephone signaling information from a calling party, parsing a telephone number from the telephone signaling information, and generating a request packet comprising call session set-up information including the telephone number. The method further comprises sending the request packet to a controller, establishing a voice data channel through the controller, querying a database using the telephone number, and providing a database record to the controller. In some embodiments, providing the database record to the controller comprises packetizing the database record. Also in some embodiments, providing the database record to the controller comprises periodically querying the database for an updated record.

Yet another method of the invention is directed to enabling a multi-media session. This method comprises receiving data from a first endpoint formatted according to a first protocol and including a first correlating identifier, receiving data from a second endpoint formatted according to a second protocol and including a second correlating identifier, and providing data to a third endpoint, the data formatted according to a third protocol and comprising data from the first and second endpoints correlated according to the first and second correlating identifiers. In some embodiments, the method further comprises requesting the data from the second endpoint by sending the first correlating identifier to the second endpoint. In some embodiments, receiving data from the first endpoint formatted according to the first protocol and including the first correlating identifier comprises receiving voice data from a calling party formatted according to a telephony protocol and including a telephone number. In some of these embodiments, receiving data from the second endpoint formatted according to the second protocol and including the second correlating identifier comprises receiving a database record from a database formatted according to a database protocol and including the telephone number. In some of the latter embodiments, providing data to the third endpoint comprises providing packetized data to a controller of a PSAP, and the third protocol is a packet-based protocol.

BRIEF DESCRIPTION OF DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> is a schematic representation of a Public Safety Answering Point (PSAP) according to the prior art.

<figref idref="DRAWINGS">FIG. 2</figref> is a schematic representation of a PSAP according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 3</figref> is a schematic representation of exemplary subsystem components of a gateway according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart representing an exemplary embodiment of the method of the invention.

<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart representing another exemplary embodiment of the method of the invention.

<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart representing another exemplary embodiment of the method of the invention.

<figref idref="DRAWINGS">FIG. 7</figref> is a flowchart representing another exemplary embodiment of the method of the invention.

DETAILED DESCRIPTION OF THE INVENTION

Phone services that employ networks for packet-based data transmission are becoming increasingly popular. Such services are commonly referred to as IP telephony, Voice over the Internet (VOI), or Voice over IP (VoIP). Networks that support such services will be referred to herein generally as packet-based networks, and the service providers will be referred to herein generally as packet-based service providers.

The invention is directed to methods and apparatus for the inter-working of electronic media operating under disparate protocols. Multiple embodiments of the present invention are particularly directed to the context of systems for receiving emergency calls. For example, in many locations PSAPs and the telephone systems to which they are connected (<figref idref="DRAWINGS">FIG. 1</figref>) principally operate under telephony protocols for handling analog or digital voice data. The present invention allows newer technologies, such as VoIP, that operate under completely different protocols to be inter-worked with a PSAP controller such that an emergency call placed through a packet-based service provider over a packet-based network can be handled by a PSAP controller. Moreover, location and other data (collectively referred to herein as auxiliary data) that can be transmitted over the packet-based network along with the telephone signaling information and the voice data can be provided to the PSAP more efficiently than if the auxiliary data were obtained from the usual database <b>108</b> (<figref idref="DRAWINGS">FIG. 1</figref>). Thus, both voice and location information, in the protocol of the packet-based service provider, are provided to the PSAP according to the protocols that the PSAP is configured to accept.

In the same context of systems for receiving emergency calls, the present invention also provides for inter-working between emergency calls made over the PSTN, digital location information from a database, and packetized data according to a protocol, such as Session Initiation Protocol (SIP), suitable for more modern packet-based PSAP controllers. The present invention further provides for inter-working between calls transmitted over packet-based networks, location information from a database, and packetized data according to a protocol suitable for a packet-based PSAP controller, where the voice and/or location information may be formatted according to protocols other than those that the PSAP is configured to accept.

Although the present invention is illustrated herein with respect to systems for emergency communications, it will be appreciated that the present invention can also be applied to other situations where electronic media operating under disparate protocols need to be inter-worked. For example, cellular telephone calls, text messaging, radio and television broadcasts, and other packet-based communications, can also be inter-worked.

The present invention will first be described with reference to a PSAP configured to include a gateway device that provides desired functionality. <figref idref="DRAWINGS">FIG. 2</figref> illustrates an exemplary PSAP <b>200</b> of the present invention. PSAP <b>200</b> includes a controller <b>202</b> that, in some embodiments, is a controller <b>102</b> (<figref idref="DRAWINGS">FIG. 1</figref>) of the prior art (also referred to herein as a “legacy” controller) while in other embodiments, the controller <b>202</b> is a packet-based controller. PSAP <b>200</b> also includes a gateway <b>204</b> coupled to the controller <b>202</b>. The functionality of the gateway <b>204</b> depends on the type of controller <b>202</b> to which it is coupled. Exemplary embodiments where the controller <b>202</b> is a legacy controller will be described first, followed by exemplary embodiments where the controller <b>202</b> is packet-based.

In those embodiments in which controller <b>202</b> is a legacy controller, telephone signaling information from a selective router <b>106</b> is received by the controller <b>202</b> over a voice trunk <b>206</b> according to a protocol such as CAMA or BRI and routed to an available terminal <b>104</b> to be answered by a call taker as described above. In these embodiments, the controller <b>202</b> is coupled to a database <b>108</b>, typically by a serial interface, as also described above. In order to accommodate calls made through a packet-based service provider over the packet-based network <b>120</b>, the gateway <b>204</b> communicates with the packet-based network <b>120</b> according to protocols of the packet-based network <b>120</b> for formatting and routing packets. The gateway <b>204</b> transforms telephone signaling information and voice data between packet-based and telephony protocols and sends the telephone signaling information, and later the voice data, to the controller <b>202</b> over a voice trunk <b>208</b>. In this way, an emergency call originally presented to the PSAP <b>200</b> according to packet-based protocols is sent to the legacy controller <b>202</b> according to telephony protocols over a traditional voice truck <b>208</b> as if it had been routed from the selective router <b>106</b> (<figref idref="DRAWINGS">FIG. 1</figref>). It will be appreciated that voice data originating at the terminal <b>104</b> is also sent over the voice trunk <b>208</b> from the controller <b>202</b> to the gateway <b>204</b> where it is converted between protocols to be sent across the packet-based network <b>120</b>.

Additionally, many packet-based protocols allow auxiliary data, such as location information, to be associated with the telephone signaling information or the voice data. Location information can be expressed, for example, by a street address, GPS coordinates, and so forth. In these embodiments, the gateway <b>204</b> parses the auxiliary data from either the telephone signaling information or the voice data and transforms the auxiliary data into a protocol such as that used by the database <b>108</b>. The auxiliary data can be buffered by the gateway <b>204</b> or immediately sent across a line <b>210</b> to the controller <b>202</b>. In this way, the gateway <b>204</b> can mimic the functionality of the database <b>108</b> by providing the auxiliary data according to the expected protocol, however without much of the delay associated with searching the database <b>108</b> for records.

In those embodiments in which the controller <b>202</b> is packet-based, and therefore operates under protocols disparate from the telephony protocols used by the selective router <b>106</b>, calls from the selective router <b>106</b> are instead received by the gateway <b>204</b>, again over a voice trunk <b>209</b>. The telephone signaling information and voice data are transformed by the gateway <b>204</b> into packet-based protocols recognizable by the controller <b>202</b> and sent to the controller <b>202</b> over a line <b>212</b>.

In some of these embodiments, the gateway <b>204</b> is connected to the database <b>108</b> by a line <b>214</b>. Here, location information is obtained from the database <b>108</b> by the controller <b>202</b> through the gateway <b>204</b> because of the disparate protocols between the database <b>108</b> and the controller <b>202</b>. Accordingly, the gateway <b>204</b> queries the database <b>108</b> as if it were a legacy controller <b>102</b> (<figref idref="DRAWINGS">FIG. 1</figref>) and transforms the location information received from the database <b>108</b> into a packet-based protocol recognized by the controller <b>202</b>. In some instances, the packet-based protocol permits the location information to be sent over the same channel as the voice data. In this way, the packets received by the packet-based controller <b>202</b> from the gateway <b>204</b> are formatted according to a protocol such that they appear to be from a packet-based service provider even though the voice data and location information originated from separate sources according to disparate protocols. It will be appreciated that voice data originating at the terminal <b>104</b> is likewise routed through the controller <b>202</b> and over line <b>212</b> to the gateway <b>204</b> where it is transformed into a telephony protocol for transmission back to the selective router <b>106</b>. Thus, a modern packet-based controller <b>202</b> for use in conjunction with a packet-based network <b>120</b> can also be inter-worked with standard telephony equipment.

In still other embodiments, the gateway <b>204</b> can enable emergency calls between a packet-based controller <b>202</b> and a packet-based network <b>120</b>. In these embodiments, the gateway <b>204</b> receives telephone signaling information, voice data, and potentially auxiliary data according to a first set of packet-based protocols and transmits these data to the controller <b>202</b> according to a second set of packet-based protocols that may be either completely the same, partially the same, or completely different than the first set of packet-based protocols. Where any of the protocols of the network <b>120</b> and the controller <b>202</b> are different, the gateway <b>204</b> converts the data between the different protocols.

Turning to <figref idref="DRAWINGS">FIG. 3</figref>, a schematic representation is provided of some exemplary subsystem components of an embodiment of the gateway <b>204</b>. It will be appreciated that in some embodiments individual subsystem components may be omitted where their functions are included in other subsystem components. Likewise, some subsystem components may be omitted where the functionality is not required for the particular embodiment. Further, numerous physical implementations are possible, including placing all of the subsystem components on a single computer chip, distributing the subsystem components across one or more system boards, implementing subsystem components in separate chasses connected by communication networks, etc. Moreover, although the gateway <b>204</b> is shown as a separate unit from the controller <b>202</b> in <figref idref="DRAWINGS">FIG. 2</figref>, it will be appreciated that all of the functionality of the gateway <b>204</b> can be readily integrated into the controller <b>202</b>.

In <figref idref="DRAWINGS">FIG. 3</figref>, the gateway <b>204</b> comprises a bus <b>302</b> for providing communication between the various components of the gateway <b>204</b>. Three I/O interfaces <b>304</b>, <b>306</b>, and <b>308</b> provide connectivity for analog or digital voice data, database data, and packet data, respectively. An operating system (OS) <b>310</b> controls functions of the terminal <b>104</b> (<figref idref="DRAWINGS">FIG. 1</figref>) including scheduling tasks, allocating storage, and so forth. A memory <b>312</b> can comprise a mass storage device such as a disk drive, a random access memory device, or combinations of both of these. The memory <b>312</b> allows instructions to be stored and data to be buffered. A central processing unit (CPU) <b>314</b> can be, for example, a microprocessor chip. The central processing unit <b>314</b> provides data processing to components of the gateway <b>204</b> such as the OS <b>310</b>. A digital signal processor (DSP) <b>316</b> typically manages aspects of the conversion of analog voice data to digital data including de-jitter buffers, codec functions, echo cancellation, and transport frame (such as real-time transport protocol (RTP)) assembly/de-assembly. In some embodiments, the functionality of the DSP <b>316</b> is provided instead by the CPU <b>314</b>.

Call session and packet protocol stacks <b>318</b> and <b>320</b> provide the means for interpreting the data structures and messaging protocols associated with packet-based call sessions. Telephony signaling module <b>322</b> provides necessary logic for interpreting and generating telephony signaling protocols, tones, and so forth. Database protocol stacks <b>324</b> provides necessary logic for interpreting and responding as a database to remote queries, and for making queries and interpreting responses from a remote database. Accordingly, database protocol stacks <b>324</b> can act as either a client-side or a server-side of a database transaction protocol.

Auxiliary information gateway application <b>326</b> integrates the other components of the gateway <b>204</b> in a logical framework that enables inter-working between the different communication systems coupled to the gateway <b>204</b>. Accordingly, the auxiliary information gateway application <b>326</b> directs data from one interface to another through appropriate protocol conversions, either merging data from disparate protocols, splitting data in one protocol into several different protocols, or simply converting data between two protocols. Additionally, the auxiliary information gateway application <b>326</b> can assign a call session identifier to each call session and keep a log of call sessions. It will be appreciated that the functionality of the auxiliary information gateway application <b>326</b> can be readily integrated into other subsystem components, such as the call session protocol stack <b>318</b>.

The three I/O interfaces <b>304</b>, <b>306</b>, and <b>308</b> provide connectivity for analog or digital voice data, database data, and packet data, respectively. The I/O interface <b>304</b> connects to a voice trunk to enable analog or digital voice data to be sent and received. The telephony I/O interface <b>304</b> can support, for example, an analog loopstart circuit employing a “tip” and “ring” wire such as is used in residences or commonly called “1 MB circuits” in business environments, a centralized automated message accounting (CAMA) circuit such as is used by 911 emergency call centers in the United States, E&amp;M trunks such as are used for inter-PBX connectivity, T-1/E-1 channel associated signaling (CAS) circuits that provide digital versions of the above interfaces, Integrated Services Digital Network (ISDN) interfaces such as Basic Rate Interface (BRI) and Primary Rate Interface (PRI), and so forth. The database I/O interface <b>306</b> connects to a data line for sending and receiving data such as requests to, and records from, a database <b>108</b> (<figref idref="DRAWINGS">FIG. 1</figref>; e.g., an ALI database). The database I/O interface <b>306</b> can be, for instance, a serial port or a modem connection for serial communication to a remote database. The packet I/O interface <b>308</b> is a packet call session interface for connecting to a packet-based network such as network <b>120</b> (<figref idref="DRAWINGS">FIG. 2</figref>). The packet I/O interface <b>308</b> can be configured to support, for example, SIP or H.323. It will be understood that although the gateway <b>204</b> is shown as having one of each of the I/O interfaces <b>304</b>, <b>306</b>, and <b>308</b>, the gateway <b>204</b> may include more than one of any of these interfaces. Additionally, I/O devices that are appropriate for other types of communications protocols may also be integrated into the gateway <b>204</b>. These can include SS#7 signaling links from traditional service provider telephony networks, serial console connections for local administration, time synchronization interfaces, serial or other interfaces for synchronization with computer-aided dispatch applications, alarm or monitor interfaces for providing audio, visual, and other notification methods in the event of system faults, and so forth. Such embodiments include modules analogous to the protocol stacks <b>318</b> and <b>320</b> and the TDM/Telephony signaling module <b>322</b> to provide necessary logic for handling the data structures and messaging protocols associated therewith.

The operation of the PSAP <b>200</b> will be described, by way of several examples, with reference to <figref idref="DRAWINGS">FIGS. 2 and 3</figref>. Examples will be given where the controller is a prior art controller <b>102</b> (<figref idref="DRAWINGS">FIG. 1</figref>) and the call originates over a network <b>102</b> and is received by the gateway <b>204</b> either with or without location information. Examples will then be given where the controller is a packet-based controller <b>202</b>.

A first example is represented by a flowchart in <figref idref="DRAWINGS">FIG. 4</figref>. With reference to <figref idref="DRAWINGS">FIGS. 2, 3</figref>, and <b>4</b>, an emergency call that does not include location information is initiated by a calling party over the network <b>120</b> and sent through the gateway <b>204</b> to the controller <b>202</b> that is a legacy controller such as controller <b>102</b> (<figref idref="DRAWINGS">FIG. 1</figref>). The controller <b>202</b> signals the terminal <b>104</b> and queries the database <b>108</b>. When the terminal <b>104</b> accepts the call, a channel for voice data is established through the controller <b>202</b> and through the gateway <b>204</b>. Furthermore, and the controller <b>202</b> provides a record from the database <b>108</b> to the terminal <b>104</b>.

More specifically, in a step <b>410</b> a request packet is received by the gateway <b>204</b> from the network <b>120</b> through packet I/O interface <b>308</b>. The request packet comprises call session set-up information including a phone number of the calling party. The request packet may be organized according to any number of available protocols. For example, a Session Initiation Protocol (SIP) Invite packet can include the call session set-up information in a header of the packet. A request packet can also be a H.225 Setup packet per the H.323 protocol. Those of ordinary skill will be able to make use of standards documents for specific protocols to implement the present invention. Examples of relevant standards documents for SIP can be found at http://www.ietf.org/html.charters/sip-charter.html and relevant standards documents for H.323 can be found at http://www.itu.int/rec/recommendation.asp?type=folders&amp;lang=e&amp;parent=T-REC-H.323.

In this first example, the auxiliary information gateway application <b>326</b> uses the protocol stacks <b>318</b>, <b>320</b> to parse the call session set-up information from the request packet, shown as step <b>420</b> in <figref idref="DRAWINGS">FIG. 4</figref>. In a step <b>430</b>, the auxiliary information gateway application <b>326</b> uses the TDM/Telephony signaling module <b>322</b> to generate telephone signaling information from the call session set-up information. The telephone signaling information is generated in a protocol, such as CAMA or BRI, which is appropriate for the controller <b>202</b>. The telephone signaling information in step <b>440</b> is then sent through the telephony I/O interface <b>304</b> to the controller <b>202</b> which signals the terminal <b>104</b>. In step <b>450</b>, the controller <b>202</b> uses the phone number included in the signaling information to query the database <b>108</b>. In step <b>460</b>, the database returns those records associated with the phone number to the controller <b>204</b>, which passes the records to the terminal <b>104</b>. Examples of relevant standards documents for ALI data transmission can be found at http://www.nena.org/9-1-1TechStandards/nena_recommended_standards.htm.

Once the call is answered at the terminal <b>104</b>, a voice data channel is established in step <b>470</b> between the terminal <b>104</b> and the calling party through the controller <b>202</b> and the gateway <b>204</b>. Voice data from the calling party is transmitted over the network <b>120</b> in packets according to a protocol, such as SIP or H.323, and received by the gateway <b>204</b> through the packet I/O interface <b>308</b>. The auxiliary information gateway application <b>326</b> uses the protocol stacks <b>318</b>, <b>320</b> to assemble the voice data packets, and uses the TDM/Telephony signaling module <b>322</b> to produce voice data in an analog signal appropriate for the controller <b>202</b>. The analog signal is sent out of the gateway <b>204</b> through the telephony I/O interface <b>304</b> to the controller <b>202</b> and to the terminal <b>104</b>. Similarly, voice data from the terminal <b>104</b> is received at the gateway <b>204</b> through the telephony I/O interface <b>304</b>. The auxiliary information gateway application <b>326</b> uses the TDM/Telephony signaling module <b>322</b> and the protocol stacks <b>318</b>, <b>320</b> to assemble the voice data into packets that are transmitted back to the calling party through the packet I/O interface <b>308</b>.

A second example is illustrated by the flowchart in <figref idref="DRAWINGS">FIG. 5</figref>. With reference to <figref idref="DRAWINGS">FIGS. 2, 3</figref>, and <b>5</b>, an emergency call that includes location information is initiated by a calling party over the network <b>120</b>. A request packet that can comprise the location information is sent through the gateway <b>204</b> to the legacy controller <b>202</b>. The controller <b>202</b> parses the call session set-up information and location information from the request packet and signals the terminal <b>104</b>. When the terminal <b>104</b> accepts the call, a channel for voice data is established as in the example above. The location information can be either supplied immediately to the controller <b>202</b>, or it can be stored until the controller <b>202</b> makes a request for it. Updated location information can also be sent to the controller <b>202</b> and to the terminal <b>104</b> during the call.

More specifically, in a step <b>510</b>, a request packet is received by gateway <b>204</b> from the network <b>120</b> through the packet I/O interface <b>308</b>. In this example, the request packet comprises both call session set-up and location information. For example, a SIP Invite packet can include the call session set-up in the header of the packet and location information in a body of the packet. The auxiliary information gateway application <b>326</b> uses the protocol stacks <b>318</b>, <b>320</b> in a step <b>520</b> to parse the call session set-up and the location information from the request packet. In a step <b>530</b>, the call session set-up information is converted into telephone signaling information. Next, in a step <b>540</b> the telephone signaling information is sent to the controller <b>220</b>. Subsequently, in a step <b>550</b>, a voice data channel is established. Steps <b>530</b>, <b>540</b>, and <b>550</b> are performed in the same manner as in the embodiment of <figref idref="DRAWINGS">FIG. 4</figref>.

Rather than have the controller <b>202</b> obtain location information by retrieving a record from the database <b>108</b>, in this example, the location information is already at the gateway <b>204</b>. In step <b>560</b>, the auxiliary information gateway application <b>326</b> uses the database protocol stacks <b>324</b> to format the location information as a record according to a protocol used by the database <b>108</b>.

In a step <b>570</b>, the record is provided to the controller <b>202</b> by the gateway <b>204</b>. In some instances the location information is sent directly to the controller <b>202</b> through the database I/O interface <b>306</b>, while in other instances, providing the record to the controller <b>202</b> includes storing the record in a buffer such as memory <b>312</b> for later delivery. In those instances in which the record is stored, the gateway <b>204</b> merely mimics the functionality of the database <b>108</b>. Accordingly, instead of querying the database <b>108</b> for the record, the controller <b>202</b> requests the record from the gateway <b>204</b> by sending the telephone number over the database I/O interface <b>306</b>. The auxiliary information gateway application <b>326</b> recognizes the phone number as a request for a location record and returns the stored record associated with the phone number over the database I/O interface <b>306</b> to the controller <b>202</b>. It will be understood that in order to properly request the record from the gateway <b>204</b> rather than from the database <b>108</b>, the controller <b>202</b> needs to be configured to make location record requests over line <b>210</b> when a voice data channel is established over the particular voice trunk <b>208</b> that is connected to the gateway <b>204</b>.

The operation of the PSAP <b>200</b> will be further described by way of several examples in which the controller is a packet-based controller <b>202</b>. In these examples, the gateway <b>204</b> allows the controller <b>202</b> to either communicate with a selective router <b>106</b> or a network <b>120</b>. Thus, the controller <b>202</b> within the PSAP <b>200</b> can be modernized to take advantage of IP protocols while still being able to communicate with the existing infrastructure.

In a third example, and with reference to <figref idref="DRAWINGS">FIGS. 2, 3</figref>, and <b>6</b>, an emergency call is initiated by a calling party and directed to the PSAP <b>200</b> by the selective router <b>106</b>. Here, in a step <b>610</b>, telephone signaling information is transmitted through telephony I/O interface <b>304</b>. In a step <b>620</b>, the auxiliary information gateway application <b>326</b> uses the TDM/Telephony signaling module <b>322</b> and the protocol stacks <b>318</b>, <b>320</b> to parse the telephone number of the calling party from the telephone signaling information. The telephone number can be stored by the gateway <b>204</b>, and in some embodiments the phone number is stored in conjunction with a call session identifier. In a step <b>630</b>, a request packet including call session set-up information such as the phone number is generated and sent over the packet I/O interface <b>308</b> to the controller <b>202</b> which signals the terminal <b>104</b>. Once the terminal <b>104</b> accepts the call, a channel for voice data is established through the controller <b>202</b> and the gateway <b>204</b> in a step <b>640</b>. The gateway <b>204</b> maintains the channel for voice data by performing the same conversions between analog telephony and packetized voice data described above with respect to the first example of <figref idref="DRAWINGS">FIG. 4</figref>.

In the present example, location information is obtained by the gateway <b>204</b> from the database <b>108</b> and passed to the controller <b>202</b>. In a step <b>650</b>, the auxiliary information gateway application <b>326</b> uses the phone number of the calling party, parsed from the telephone signaling information, to request records associated with the telephone number from the database <b>108</b>. The auxiliary information gateway application <b>326</b> uses the data protocol stacks <b>324</b> and the protocol stacks <b>318</b>, <b>320</b> in a step <b>660</b> to packetize the returned records and sends the records to the controller <b>202</b>.

In some instances, the database <b>108</b> may be updated during the call session. For example, wireless phone networks can determine the location of a phone through triangulation between multiple cell phone towers. The location information can be transmitted to the database <b>108</b> through an independent channel so that the database <b>108</b> is periodically updated. To take advantage of periodically updated information in the database <b>108</b>, however, the controller <b>202</b> needs to be configured to periodically query the gateway <b>204</b>, or be provided with some other means to alert the controller <b>202</b> that updated location information has become available.

In a fourth example, and with reference to <figref idref="DRAWINGS">FIGS. 2, 3</figref>, and <b>7</b>, in a step <b>710</b>, an emergency call is initiated by a calling party and a request packet is directed to the PSAP <b>200</b> across the network <b>120</b> and through packet I/O interface <b>308</b>. The auxiliary information gateway application <b>326</b>, in a step <b>720</b>, uses the protocol stacks <b>318</b>, <b>320</b> to direct the request packet back through the packet I/O interface <b>308</b> to the controller <b>202</b> which signals the terminal <b>104</b>. When the terminal <b>104</b> accepts the call, in a step <b>730</b>, a voice data channel is established through the controller <b>202</b> and the gateway <b>204</b>. In this instance, although the call session set-up information and voice data are both received and sent by the gateway <b>204</b> in packets, the gateway <b>204</b> may still have to perform protocol translations. For example, the controller <b>202</b> may operate according to the SIP protocol while the network <b>120</b> operates according to the H.323 protocol, thus the auxiliary information gateway application <b>326</b> uses the protocol stacks <b>318</b>, <b>320</b> to convert packets between the two protocols.

In a step <b>740</b>, location information is provided to the controller <b>202</b>. In this example, as in the third example of <figref idref="DRAWINGS">FIG. 6</figref> above, location information can be obtained by the gateway <b>204</b> from the database <b>108</b> and passed to the controller <b>202</b>. Alternatively, location information can be obtained from the request packet, if available. In the first alternative, the auxiliary information gateway application <b>326</b> uses the phone number of the calling party, parsed from the request packet, to request records associated with the telephone number from the database <b>108</b>. The auxiliary information gateway application <b>326</b> then uses the data protocol stacks <b>324</b> and the protocol stacks <b>318</b>, <b>320</b> to packetize the returned records and sends the records to the controller <b>202</b>. As noted, location information can also be obtained from the request packet, if available. In these instances, the gateway <b>204</b> can provide location information from the request packet to the controller <b>202</b> as in the second example of <figref idref="DRAWINGS">FIG. 5</figref>, described above.

It will be further appreciated that location information can also be transmitted in update packets as needed to reflect changes in location. Update packets received by the gateway <b>204</b> can be directed to the controller <b>202</b>, with a protocol conversion, if necessary, so that newer location information can be made available at the terminal <b>104</b>. It should be noted that in the second example, above, in which location information is provided in the request packet but the controller <b>202</b> happens to be a legacy controller, in some instances, updated location information received in an update packet can also be provided to the controller <b>202</b>. In this case, however, the controller <b>202</b> would need to be configured to periodically query the gateway <b>204</b>, or be provided with some other means to alert the controller <b>202</b> that updated location information is available.

Moreover, it will be understood that location information is but one example of the auxiliary data that can be provided over the network <b>120</b> to the gateway <b>204</b>. Auxiliary data can also comprise image, video, text, and so forth. Auxiliary data can be received either on the same channel as voice data (“in-band”) or over a separate channel (“out-of-band”). Accordingly, where the controller <b>202</b> operates according to a packet-based protocol, the gateway <b>204</b> can pass the auxiliary data to the controller <b>202</b> which may then communicate the auxiliary data to the terminal <b>104</b>. In order to handle auxiliary data, including converting the auxiliary data between protocols, the gateway <b>204</b> can comprise, as necessary, additional I/O devices and modules analogous to the protocol stacks <b>318</b> and <b>320</b> and the TDM/Telephony signaling module <b>322</b>.

It will also be understood that the present invention is not limited to emergency call systems and can also be readily applied to other Computer-Telephony-Interface (CTI) applications, such as customer relationship management (CRM) applications, that perform database queries using calling party phone numbers, for instance, as database keys. More generally still, the present invention is readily applicable where communications systems that operate under disparate protocols need to be integrated. Typically, where two media types with different protocols are brought together each will comprise a correlating identifier that the gateway <b>204</b> can use to associate the data from the two endpoints. In the examples provided above, the usual correlating identifier is a phone number, thus the gateway <b>204</b> knows to associate the record returned from the database <b>108</b> with the voice data for the same phone number. Although the correlating identifier will commonly be the same for each communication medium being brought together, this is not a requirement. Accordingly, each communication medium can have a unique correlating identifier so long as the gateway <b>204</b> has some means, such as a look-up table, by which to associate the different correlating identifiers.

In the foregoing specification, the present invention is described with reference to specific embodiments thereof, but those skilled in the art will recognize that the present invention is not limited thereto. Various features and aspects of the above-described invention may be used individually or jointly. Further, the present invention can be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. The specification and drawings are, accordingly, to be regarded as illustrative rather than restrictive.