HK1148622B - Method and apparatus for emergency services number alerting in an internet protocol network - Google Patents

Description

Method and apparatus for emergency service number alerting in an internet protocol network

Technical Field

The present invention relates generally to electronic Internet Protocol (IP) related communications based on telephony and information. More particularly, the present invention relates to the identification of emergency situations occurring at a given geographic location of a voice over IP (VoIP) device, and the appropriate alerting of the subsequent Emergency Services Notification (ESN) telephone number.

Background

Emergency services have been the subject of widespread standardization throughout the world for many years. Telephone users benefit from this standardization by virtue of the establishment of, among other things, an Emergency Services Notification (ESN) system. In north america, the popular ESN system is standardized on the dialing sequence 911. While the purpose of each ESN system is to quickly and reliably request assistance when an emergency situation occurs, other jurisdictions still choose different alternative sequences. Thus, by dialing an ESN telephone number in the geographic area served by the ESN system, the telephone user may request any type of emergency assistance. In order for such services to be available, Public Switched Telephone Network (PSTN) providers in the area must route all of these calls to the appropriate call answering center. These call answering centers are often municipal offices, such as the police department.

The original ESN system simply detected the ESN dialing sequence (e.g., 911) and routed the emergency telephone call to a particular answering point. In these early ESN systems, no subscriber information or high priority call processing was included. However, many ESN system operators quickly recognize that the critical information required by most callers is his or her location. With these systems, assistance cannot be dispatched quickly when the nature of the emergency prevents that information from being transmitted to the answering point.

Later, many jurisdictions installed improved systems including techniques for reporting the Directory Number (DN) of a calling party directly to a call answering center (typically referred to as a Public Safety Answering Point (PSAP)). The DN information is contrasted with a location database that identifies the geographic location of the calling party in need of assistance via a well-known mechanism known as automatic number identification/automatic location identification (ANI/ALI). ANI/ALI is a mechanism to match a particular telephone DN to a physical resource (e.g., port or connection). The physical resource is then compared to the geographic location data or the citizen address. Thus, the ANI/ALI mechanism is used to determine which PSAP owns the jurisdiction by comparing the citizen address with the responsible agency, whereby the DN information is used by the PSAP to dispatch the emergency services team to the location of the caller.

The accuracy of the location database relies on a consistently strict use of the Citizens Addressing System (CAS) to provide a unique address for each possible original telephone number. In practice, CAS is often inaccurate. This is particularly true in situations involving users who cannot effectively join the ESN system, since their private branch exchange (PBX) telephone system has no real way to report location information to the PSTN. For example, a commercial, industrial, educational, or governmental agency may have hundreds of telephone devices located in various buildings over a wide geographic area, although a "911 call" from any one of them may identify only one location.

Also, existing ANI/ALI mechanisms typically rely on a one-to-one correspondence of physical resources to each DN entry. As alluded to above, for a PBX telephone system, the basic emergency function of any such ESN system fails when multiple DN entries are associated with a single resource, such as a telephone system element (e.g., a PBX that acts as a concentrator for multiple telephone devices to a telephone trunk circuit). The ANI/ALI problem within ESN systems is further exacerbated by the emergency situation of Internet Protocol (IP) based phones. IP telephony uses a packet-switched fabric that allows multiple users to share communication resources in an efficient manner via voice over IP (VoIP) technology. For example, in a PBX scheme, sharing a physical channel through VoIP devices means that there is no one-to-one correspondence of physical resources to DN entries. Accordingly, ESN system failures also occur in situations where a calling party uses a VoIP device to place an emergency services call. In this case, a single DN entry may be associated with a single resource, such as a VoIP phone, but the nature of VoIP phones often prevents accurate identification of the user's geographic location when emergency assistance is required.

IP telephony providers have chosen a number of expedients to provide extrinsic reliability for ESN systems. In most cases, these IP phone providers simply require their customers to read and agree to a duty of disclaimer (which describes the ESN system as being based on the address at which the customer signs up for VoIP service offerings). This approach relies on: (a) the exact address reported by the user; (b) a static user; and, (c) PSAP cooperation of the ESN system. The latter problem is questionable because many jurisdictions already have legislation to exclude any auto-dialing mechanism to place ESN calls. Therefore, IP telephone providers often use call centers to handle emergency calls.

The IP telephony provider call center operates such that emergency calls placed on the VoIP service are redirected to the call center where a human operator concludes the nature of the call and whether the caller is located at the reported address. A human operator at the call center then forwards the emergency call to a pre-designated PSAP. However, such emergency calls are often forwarded from the IP telephony provider's call center and sent to a supervisory, supervisory or general purpose telephone line where the answering party is not a trained ESN call-recipient. Emergency calls may ring for a long time before being answered, or not be answered at all, since those lines are not assumed to be associated with emergency events. Even after being answered, the situation is interpreted to the answering party before forwarding it to the call recipient of the PSAP.

Another known expedient involves maintaining a conventional telephone service line at each user's location. With a VoIP device, one device is used to sense the dialing of an ESN dialing sequence. The VoIP device then goes offline and dials the ESN dialing sequence on the traditional telephone circuit, such as a Plain Old Telephone Service (POTS) line. The IP-based audio is then routed to the PSAP over the POTS line connection. This solution is less effective than desired because it requires conventional circuitry to maintain the location capabilities of the ESN system.

As noted above, the nature of VoIP phones often prevents accurate identification of the user's geographic location when emergency assistance is required. A significant advantage of IP telephony for mobile users is the ability to receive "dial tones" from the location of their home, regardless of where the mobile user is located around the world. When such mobility is connected to advanced services authorized by IP telephony, it provides strong motivation for business and personal users to select such new technologies. However, IP phone mobility often defeats the expedients that IP phone providers arrange to address the problems involved with ESN systems. While efforts are underway to attempt to track the location of VoIP users through the network, there are inherent difficulties in overcoming complex spoofing and other attacks that disrupt normal network operation due to the variability of IP networks worldwide, which includes different security measures.

As conventional telephone circuits continue to give way to advanced IP-based technologies, the public's confidence in ESN systems will diminish unless the problematic aspects discussed above are addressed. The ideal solution would be to be able to maintain and enhance the existing PSAP architecture. Moreover, as part of the mainstream communication methods used by the public in their residence, emergency calls in IP technology (including VoIP in particular) have opened the need to perform services such as efficient ESN system services (e.g., 911 services). Without an effective method of performing ESN services, individual national communication authorities (ultimately responsible for ESN notifications within their given jurisdiction) may not allow for the widespread implementation of IP telephony. Therefore, there is a need to supplement existing emergency response tools within a VoIP technology environment to more effectively guide emergency responders to actual emergency locations.

Disclosure of Invention

It is an object of the present invention to obviate or mitigate at least one disadvantage of previous solutions for notifying emergency situations occurring in residential, commercial, institutional or industrial settings as determined by detection of an appropriate Emergency Services Notification (ESN) telephone number. Moreover, it is an object of the present invention to provide for the identification of emergency conditions occurring at a given geographic location of a VoIP device and to provide for subsequent appropriate ESN alerts. The present invention seeks to facilitate installation consistent with installation of an IP modem or interconnect device.

In a first embodiment, a method of emergency alerting within an IP network is provided, the method comprising: monitoring IP packet flows from one or more IP telephony devices; sensing datagrams in the IP packet stream corresponding to an ESN dialing sequence; upon sensing the ESN dialing sequence, interrupting normal packet flow from the IP telephony device to an IP telephony service provider; returning IP-based call setup information to the IP telephony device; notifying an ESN call server that the ESN dialing sequence has been sensed; and forwarding the IP packet stream to a PSAP suitable for the IP telephony device, along with location information corresponding to the civic address at which the IP telephony device is located.

In another embodiment, there is provided an apparatus for emergency alert within an IP network, the apparatus comprising: an ESN enabled device that monitors IP packet flows from one or more IP telephony devices and senses datagrams within the IP packet flows that correspond to an ESN dialing sequence; upon sensing the ESN dialing sequence, the ESN enabling device interrupts normal call flow from the IP telephony device to the IP telephony service provider and returns normal call setup information to the IP telephony device; and an ESN call server located remotely from the ESN enabled device, the ESN call server accepting notification from the ESN enabled device that the ESN dialing sequence has been sensed and forwarding the IP packet stream via a communication channel to a Public Safety Answering Point (PSAP) appropriate for the IP telephony device, along with location information corresponding to a civic address at which the IP telephony device is located.

Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.

Drawings

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

FIG. 1 is a generalized network diagram according to one embodiment of the present invention.

FIG. 1a is a generalized network diagram of another embodiment of the present invention.

Fig. 2 is a flow chart of a general procedure obtained by establishing the method according to the invention.

Fig. 2a is a block diagram illustrating a first implementation of the method according to the invention.

Fig. 2b is a block diagram illustrating a second implementation of the method according to the invention.

Detailed Description

The present invention provides a method and apparatus for identifying an emergency situation occurring at a given geographic location of an IP-based device, and the subsequent appropriate alerting of the ESN system. Although the present invention is discussed in terms of particular IP technology in the form of VoIP technology, it should be understood that any packet-based technology may benefit from the present invention without departing from the intended scope of the claims.

In general, the method and apparatus for ESN alerting based on IP networks of the present invention can be embodied in several different ways. When the IP telephony device is actually communicating with the PSAP point, the present invention can be configured such that the IP telephony device (e.g., a VoIP telephone) at the user's location is "spoofed" as if the IP telephony device were communicating with an IP service provider. Alternatively, when the communication is actually rerouted so that the IP service provider communicates with the PSAP point, the present invention can be configured so that the IP service provider itself is spoofed as if the IP service provider communicated via a normal IP telephone call. The latter configuration has the further advantage that the IP telephony device is not required to know the authentication format used by the IP service provider. In turn, the IP service provider sees the ESN call as if it were a normal call that has been forwarded by the call to another number. Still further, these two spoofing configurations can be configured to operate in the vicinity of the user as an adjunct to the IP telephony device communication line, or, alternatively, at the edge of the IP network (e.g., at a Data Over Cable Service Interface Specification (DOCSIS) level Internet connection level such as with a Digital Subscriber Line (DSL), T1 digital signal line, or as part of a modem or similar Internet connection device).

Referring to fig. 1, a generalized network diagram 100 is shown in accordance with one embodiment of the present invention. An end user 10a using the IP telephone device 10 is connected to the public internet 12. According to the present invention, an ESN enabling device 11 is interposed between an IP telephone device 10 and the public internet 12. In particular, ESN-enabled device 11 is operatively connected to IP telephony device 10 in some suitable manner by connection mechanism 101. A similar embodiment is illustrated by fig. 1a, in which fig. 1a plurality of users 10a, 10b, … 10n (where n is an integer) using a plurality of respective IP telephony devices 10a, 10', 10 "are connected to an ESN enabling device 11 by respective connection mechanisms 101, 101b, 101 n. Thus, a single ESN enabling device 11 may be connected to multiple users. Both fig. 1 and 1a serve a similar function and are therefore further described by similar reference numerals. The connection mechanism 101 may be a known type of cable, such as, but not limited to, a typical class 5, class 5e or class 6 ethernet cable having RJ45 terminals. Although such cables are discussed, it should further be appreciated that ESN enabled device 11 according to the present invention may be connected to IP telephony device 10 in some wired or wireless manner, or alternatively, may be integrated into IP telephony device 10 without departing from the intended scope of the claims.

ESN-enabled device 11 is connected to public internet 12 through IP network interface 102. The interface 102 may be any wired or wireless means of accessing the public internet 12. Further, interface 102 may include one or more elements such as, but not limited to, any standard modem, cable modem, wireless modem, or any intervening local area network or high speed access mechanism. Still further, it should be appreciated that ESN-enabled device 11 according to the present invention may be integrated into any of these elements within interface 102, such as, but not limited to, a cable modem.

As previously mentioned, it should be understood that ESN-enabled device 11 may be constructed integral with connection mechanism 101 or as an add-on to connection mechanism 101, and alternatively may be constructed as part of a modem or similar internet connection device within interface 102 at an edge of an IP network (e.g., at DSL, T1, or DOCSIS levels). Whether ESN-enabled device 11 is a stand-alone device (e.g., "dongle"), or integrated into any element within IP telephone device 10 or within interface 102, ESN-enabled device 11 according to the present invention is embodied in computer software in some form of integrated chip hardware (e.g., without limitation, an Application Specific Integrated Chip (ASIC)).

As further shown in fig. 1, an IP telephony service provider 13 is operatively connected to the IP telephony device 10 via a cable 101, an ESN enabled device 11, an IP network interface 102, the public internet 12, and a service provider interface 103, wherein the service provider interface 103 connects the IP telephony service provider 13 to the public internet 12 in a well-known manner. IP phones operated by the IP phone service provider 13 are well known in the VoIP art and will not be discussed further herein as such are beyond the scope of the present invention.

According to the present invention, when an ESN enabled device 11 is initially installed at a particular physical location or the ESN enabled device 11 is moved to a new geographic location, the ESN enabled device 11 cannot become active until the ESN enabled device 11 is approved by the ESN call server 14. ESN call server 14 is operatively coupled to ESN enabling device 11 via IP network interface 102, public internet 12, and ESN call server interface 104, wherein ESN call server interface 104 connects ESN call server 14 to public internet 12 in a known manner. ESN call server 14 selectively communicates with PSAP15 where all emergency calls are selectively routed to PSAP15 via communication channel 105 as further described below. In the case where ESN call server 14 and PSAP15 are each relatively close or remote, such communication between ESN call server 14 and PSAP15 may be accomplished in any wired or wireless manner. These communication details may vary without departing from the intended scope of the claims and are not further described herein as they are readily apparent to those skilled in the network arts.

As can be further seen in fig. 1, PSAP15 is operatively connected to ESN call server 14 via communication circuit 105, where communication circuit 105 may be a plurality of circuits, any of which will carry voice traffic received by ESN call server 14 from IP telephony provider 13, and IP telephony provider 13 redirects calls from IP telephony device 10 carried via internet interface 103, public internet 12, and ESN call server IP interface 104. In addition to the plurality of communication circuits 105, PSAP15 may also be connected to ESN call server 14 via a private or public internet connection 106 for the purpose of receiving a civic address belonging to the user. Alternatively, such citizen address information may be transmitted via a plurality of communication circuits 105 using such communication mechanisms, as will be apparent to those skilled in the art of telephony.

The above-mentioned activation process occurs either during the initial installation of ESN enabled device 11 or during a subsequent "re-installation" when moving ESN enabled device 11 to a new geographic location requires the installer of ESN enabled device 11 to provide the correct civic address to ESN call server 14. While the installer may be the VoIP user 10a, typically the ESN enabled devices may also be installed by a qualified service technician installing the VoIP devices for the VoIP user 10 a. After this installation process is completed, the ESN enabling device 11 then becomes active. The correct PSAP assignment is determined by the citizen address reported by the installer, whereby each citizen address is assigned to a specific PSAP by the agent responsible for the ESN service in the operating jurisdiction. The assignment of a particular citizen address by a particular PSAP agent is beyond the scope of the present invention.

In normal VoIP operation, when a user 10a of the IP telephone device 10 wishes to place a telephone call, the user 10a enters an appropriate telephone number using well-known mechanisms (e.g., a touch-tone dial) provided within the IP telephone device 10. Via cable 101, ESN-enabled device 11, and IP network interface 102, the entered information causes IP telephony device 10 to form one or more datagram packets for submission to public internet 12. In the case where the information is used to initiate a loop of unanswered packets between the calling party and the called party, the datagram packets are routed to the IP telephony service provider 13. It is readily apparent that the called party is operatively connected to the IP telephony service provider 13 in a manner similar to the user 10a of the IP telephony device 10. This looping of unanswered packets between the calling party and the called party is done using protocols that support fast unanswered voice packet transport, such as real-time transport protocol (RTP), which is a popular protocol that defines the standard packet format for delivering audio and video over the internet. This establishes a two-way telephone conversation based on the internet using IP.

In one embodiment of the present invention, the IP telephony service provider 13 typically performs a variety of authentication, security processes and information to qualify the user 10a for service provisioning. ESN-enabled device 11 can be configured to transparently pass all of these authentication procedures and information so as not to interfere with normal qualifications and information. ESN-enabled device 11 includes a mechanism embodied in software (e.g., within an ASIC design as described above) whereby the ESN dial-string is recognized and properly formed call redirection information may be sent to IP telephony service provider 13 via public internet 12 and related interfaces. This redirection information is controlled by ESN call server 14.

In another embodiment, as is normally customary, the IP telephony service provider 13 typically performs a complex user authentication process to ensure that the user is entitled to the VoIP services provided by the IP telephony service provider 13. This authentication process is often owned by a separate IP telephony service provider 13. ESN-enabled device 11 includes a mechanism embodied in software (e.g., within an ASIC design as described above) to sense (sense) the authentication process and the associated data exchange between IP telephony device 10 and IP telephony service provider 13. ESN-enabled device 11 uses the information in the data exchange to be able to handle emergency requests (i.e., ESN calls).

When user 10a of IP telephony device 10 enters an ESN dialing sequence (e.g., "911" as used in north america), ESN enabling device 11 senses the specific datagrams associated with the dialing sequence and interrupts the normal datagram packet flow to IP telephony service provider 13. ESN enabled device 11 returns call setup information datagram packets to IP telephony device 10 so that the telephony device sees the desired sequence as if coming from IP telephony service provider 13. At the same time, ESN enabled device 11 sends a message to ESN call server 14 indicating that the ESN dialing sequence has been received by ESN enabled device 11. ESN call server 14 recognizes the unique numerical address associated with ESN enabled device 11. ESN call server 14 then compares this digital address information to the appropriately stored PSAP and civic addresses associated with ESN enabled device 11 that were stored upon initial, or subsequent, authentication of ESN enabled device 11.

Once ESN call server 14 authenticates the ESN call, ESN call server 14 sends the datagram information to ESN-enabled device 11 (informing it to send the redirection information to IP telephony service provider 13). The redirection information includes a call to redirect a telephone DN number. The IP telephony service provider 13 makes an outgoing call to the designated DN number (associated with the ESN call server 14). ESN call server 14, which has been previously announced in anticipation of an incoming call via datagram information from ESN enabled device 11, answers the incoming call, authenticates the incoming call, and then connects the call to one of the plurality of communication circuits 105 (connected to PSAP 15). Depending on the type of communications circuitry equipped, ESN call server 14 simultaneously transmits the civic address information, or the civic address information conveyed by the data communication service, through communications circuitry 105 in a prescribed format as desired by PSAP15, as will be apparent to those skilled in any telecommunications art.

It should be appreciated that communication channel 105 conveys ESN location information and telephony audio in a manner equivalent to the PSAP's previously established method of receiving ESN telephony audio. In north america, the mechanism by which the communication channel 105 operates will typically be via Integrated Services Digital Network (ISDN) telephony services. Alternatively, the present invention may utilize contact trunks, IP telephony, microwave links, or any other suitable mechanism to facilitate the delivery of ESN telephony audio and location information to PSAP15 in an accurate, real-time manner. In general, however, PSAP15 receives ESN location information and audio calls in the same established manner as it receives calls from any POTS telephone equipment. Thus, the present invention permits PSAP emergency operator 15a to receive the citizen address of a VoIP user in the same manner as a POTS caller. Furthermore, no special procedures or special training relating to the VoIP user is required. The two-way telephone audio proceeds in the normal manner and PSAP emergency operator 15a handles the call in its normal manner.

Upon conclusion of the ESN call, ESN-enabled device 11 returns to normal operation, wherein it transmits IP telephony datagram packets to IP telephony service provider 13. Advantageously, no special action is required for VoIP users to get ESN calls or to re-establish their normal operation of IP telephony services.

The present invention may also include diagnostic capabilities such that ESN call server 14 operators have the ability to maintain and test ESN enabled devices 11 remotely from the location of ESN call server 14 via a network connection. ESN call server 14 will perform a regular, time-based diagnostic test (which will measure the performance of the network connection between ESN call server 14 and ESN-enabled device 11). Furthermore, internal diagnostic testing within the ESN enabled device 11 will continuously test the integrity of the device. All detected problems are reported to the ESN call server 14 via the internet 12, captured in diagnostic files and displayed on the technician's desktop. The technician can then take corrective action to resolve the typical problem before bringing the ESN-enabled device 11 into service.

With respect to fig. 2, a general flow chart is shown, building a general procedure obtained by the method according to the invention. Although a particular procedure is shown, it is apparent that alternative steps or sequences of steps may occur without departing from the scope of the claims.

Initially, IP telephony device 10 will initiate an IP-based call in the normal manner known in the art. That is, the user 10a will enter a key sequence to initiate a telephone call. Such a call would be determined to be either a regular VoIP call to another telephone user and sent by the IP telephony service provider 13 in the normal manner, or, alternatively, an ESN call. This determination is made by ESN enabling device 11 determining that user 10a has entered a particular ESN dialing sequence. Upon determining that the call is an ESN call, ESN-enabled device 11 interrupts the normal flow of packets from IP telephony device 10 to IP telephony service provider 13. The IP-based call setup information is then spoofed in the manner of the present invention to establish a connection from the IP telephony device 10a or device 10a, 10b, … 10n to the ESN call server 14 (as shown in fig. 2 a) or to establish a connection from the IP telephony service provider 13 to the call server 14 (as shown in fig. 2 b).

In particular, ESN-enabled device 11 sends a datagram message to ESN call server 14 to alert ESN call server 14 of the fact that the ESN call will be redirected to ESN call server 14 from a specific civic address associated with the device. The datagram information contains the citizen address and the responsible PSAP. Alternatively, where the specific IP address associated with ESN enabled device 11 is used as a pointer (index) to retrieve the information, the citizen address and responsible PSAP information may be maintained in a database (not shown) associated with call server 14. Such datagram information is acknowledged by ESN call server 14 and a 'forward' datagram information is returned to ESN-enabled device 11. The 'forward' message includes the specific DN number that ESN call server 14 expects the ESN call to be able to be placed.

Once ESN-enabled device 11 receives the 'forward' datagram message, ESN-enabled device 11 forms a datagram message to IP telephony service provider 13 that tells IP telephony service provider 13 to forward all datagram packets received from IP telephony device 10 of the IP user to the DN number provided by the datagram message returned from ESN call server 14, as indicated above. When the IP telephony service provider 13 receives the datagram information, the IP telephony service provider 13 forms a call to the DN number specified by the information. The call is placed via the normally operable IP network. The call is detected by ESN call server 14 as an incoming type call to the desired DN. Further, in the case where these facilities are provided by the IP telephony service provider 13, the incoming type call may include verification of the original caller DN.

ESN call server 14 determines which of the multiple PSAP connections is appropriate for the call and transmits the citizen address of the caller using methods already established for the particular PSAP. In this manner, multiple PSAP connections can be provided using multiple communication methods. Once the citizen address has been successfully assigned to PSAP15, ESN call server 14 begins to stream VoIP audio from the incoming port through the server to outgoing PSAP communication circuit 10. PSAP operator 15a handles ESN calls starting from IP connected user 10a in the same way as any other ESN call.

Of course, the rerouting of the packet flow from user 10a to emergency service operator 15a will continue throughout the ESN call. Once the ESN call is stopped, normal packet flow to the IP telephony service provider 13 will resume in a seamless manner and transparent to the user 10a or emergency service operator 15 a.

It should be appreciated that the present invention includes several advantageous features, including the fact that ESN-enabled devices 11 are at the edge of an IP network. In this manner, ESN-enabled device 11 is physically associated with a citizen address, rather than attempting to discover the citizen address by manipulating aspects of the IP network. Thus, the present invention is similar to the conventional ESN method in which corresponding citizen addresses are associated with physical resources (i.e., copper connections). While in fact communicating with ESN call server 14 and redirecting the recovered voice signals to PSAP15 via communication channel 105, ESN-enabled device 11 also uniquely controls the remote endpoint of the normal VoIP connection connected to IP telephony device 10. This mechanism maintains proper operation of IP telephony device 10 even if ESN call traffic is redirected to ESN call server 14 and the appropriate PSAP 15. Still further, advantageously, the present invention is compatible with existing PSAP operations, such that no changes to PSAP network connections and no changes to training are required, and PSAP operators need only use standard operating procedures to handle ESN calls from IP telephony device 10.

The above-described embodiments of the present invention are intended to be examples only. Alterations, modifications and variations may be effected to the particular embodiments by those of skill in the art, and the invention is defined solely by the claims appended hereto without departing from the scope of the invention.

Claims (20)

1. A method of emergency alerting in an internet protocol, IP, network, the method comprising:

monitoring IP packet flows from one or more IP telephony devices;

sensing datagrams within the IP packet stream corresponding to an emergency services notification, ESN, dialing sequence;

upon sensing the ESN dialing sequence, interrupting normal packet flow from the IP telephony device to an IP telephony service provider;

returning IP-based call setup information to the IP telephony device;

notifying an ESN call server that the ESN dialing sequence has been sensed; and

forwarding the IP packet stream to a Public Safety Answering Point (PSAP) suitable for the IP telephony device, together with location information corresponding to the citizen address where the IP telephony device is located.

2. The method of claim 1, wherein the step of returning IP-based call setup information further comprises: establishing a connection from the IP telephony device to the ESN call server.

3. The method of claim 1, wherein the step of returning IP-based call setup information further comprises: establishing a connection from the IP telephony service provider to the ESN call server.

4. The method of claim 1, wherein the IP packet stream comprises: a datagram of voice over internet protocol, VoIP.

5. The method of claim 1, wherein the sensing is accomplished by an ESN enabled device at a network edge proximate to the IP telephony device.

6. The method of claim 1, wherein the forwarding is accomplished through the ESN call server.

7. The method of claim 6, wherein the ESN call server is at an edge of the network remote from the IP telephony device.

8. The method of claim 7, wherein the location information corresponding to the civic address where the IP telephony device is located is stored within the ESN call server.

9. The method of claim 8, wherein the location information is predetermined prior to being stored in the ESN call server.

10. The method of claim 8, wherein the sensing is accomplished by an ESN enabled device at a network edge proximate to the IP telephony device; and the location information is predetermined by a user of the IP telephony device and stored by the user via the ESN enabled device.

11. The method of claim 1, wherein said forwarding said IP packet stream to said PSAP occurs via an integrated services digital network ISDN telephone service line.

12. An apparatus for emergency alert within an internet protocol, IP, network, the apparatus comprising:

an emergency services notification, ESN, enabled device that monitors IP packet flows from one or more IP telephony devices and senses datagrams within the IP packet flows that correspond to an ESN dialing sequence; upon sensing the ESN dialing sequence, the ESN enabling device interrupts normal call flow from the IP telephony device to the IP telephony service provider and returns normal call setup information to the IP telephony device; and

an ESN call server located remotely from the ESN enabled device, the ESN call server accepting notification from the ESN enabled device that the ESN dialing sequence has been sensed and forwarding the IP packet stream via a communication channel to a Public Safety Answering Point (PSAP) appropriate for the IP telephony device along with location information corresponding to a civic address at which the IP telephony device is located.

13. The apparatus of claim 12, wherein the ESN enabled device returns the normal call setup information to the IP telephony device by establishing a connection from the IP telephony device to the ESN call server.

14. The apparatus of claim 12 wherein said ESN enabled device returns said normal call setup information to said IP telephony device by establishing a connection from said IP telephony service provider to said ESN call server.

15. The apparatus of claim 12, wherein the packet stream comprises: a datagram of voice over internet protocol, VoIP.

16. The apparatus of claim 12, wherein the ESN-enabled device is at a network edge proximate the IP telephony device.

17. The apparatus of claim 12, wherein ESN call server stores the location information corresponding to the civic address where the IP telephony device is located.

18. The apparatus of claim 12, wherein the location information is predetermined by a user of the IP telephony device and stored by the user via the ESN enabled device.

19. The apparatus of claim 12, wherein the communication channel is an integrated services digital network ISDN telephone service line.

20. The apparatus of claim 12 wherein said communication channel is a suitable mechanism for communicating ESN telephony audio and location information to said PSAP in accurate real-time selected from a group of mechanisms including contact trunks, IP telephony, and microwave links.