CA2598200C - System and method for delivering callback numbers for emergency calls in a voip system - Google Patents
System and method for delivering callback numbers for emergency calls in a voip system Download PDFInfo
- Publication number
- CA2598200C CA2598200C CA2598200A CA2598200A CA2598200C CA 2598200 C CA2598200 C CA 2598200C CA 2598200 A CA2598200 A CA 2598200A CA 2598200 A CA2598200 A CA 2598200A CA 2598200 C CA2598200 C CA 2598200C
- Authority
- CA
- Canada
- Prior art keywords
- volp
- network
- sip uri
- switch
- call
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/42195—Arrangements for calling back a calling subscriber
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1023—Media gateways
- H04L65/103—Media gateways in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1096—Supplementary features, e.g. call forwarding or call holding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
- H04M3/51—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
- H04M3/5116—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing for emergency applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
- H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
- H04M7/126—Interworking of session control protocols
- H04M7/127—Interworking of session control protocols where the session control protocols comprise SIP and SS7
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
- H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
- H04M7/128—Details of addressing, directories or routing tables
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2242/00—Special services or facilities
- H04M2242/14—Special services or facilities with services dependent on location
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Business, Economics & Management (AREA)
- Multimedia (AREA)
- General Business, Economics & Management (AREA)
- Emergency Management (AREA)
- Marketing (AREA)
- Health & Medical Sciences (AREA)
- Environmental & Geological Engineering (AREA)
- Public Health (AREA)
- Telephonic Communication Services (AREA)
Abstract
In a VoIP system, a method and apparatus for tracking emergency callers is provided. A VoIP service provider network includes a plurality of VoIP phones and is connected to an emergency service provider system. The emergency service provider system includes a call server connected to the VoIP service provider network; a subscriber database; a VPC SBC; and a media gateway for connection to a PSTN. The call server is adapted to receive an emergency call from a VoIP telephone in the VoIP network; verify if the SIP URI has a DID bound to the SIP URI; if the SIP URI does not have a DID bound to the SIP URI, obtain a temporary DID from a DID pool and temporarily bind the temporary DID to said SIP URI; and forward the call to an appropriate PSAP in the PSTN. Should the emergency call be dropped, a person at the PSAP can call back the emergency caller without unnecessary delays.
Description
SYSTEM AND METHOD FOR DELIVERING CALLBACK NUMBERS FOR
EMERGENCY CALLS IN A VOIP SYSTEM
FIELD OF THE INVENTION
In most areas of the world, a unique number is used to make an emergency call.
For North America, this number is "911", and when this number is dialed, the call is automatically routed to a Public Safety Answering Point (PSAP).
In some cases, an emergency call will be dropped, for any number of reasons.
If this occurs, most jurisdictions require that the PSAP be able to call back the person that made the call.
Currently, when a 9-1-1 call is placed by a customer in a VOIP context, a server forwards the call to a 9-1-1 gateway (3rd party call server) which routes the call to the correct Public Safety Answering Point (PSAP) that answers the call. The call delivery is generally done using NENA i1, 12, or i3 standards. The PSAP must be able to call back the caller in case the call is disconnected.
Many VolP users have a Direct Inward Dial (DID) associated with their phone line.
This allows anyone connected to the Public Switch Telephone Network (PSTN) to = call the the VolP user. For such users, the 911 system can obtain the caller's callback number from the SIP signaling messages by reading the SIP URI field.
The field is in the form DIDAprovider.com, where the DID is the VolP user's DID, and the provider.com is the user's domain.
In many cases, it is becoming more common to see VolP phones without assigned DID numbers. This is often the case in Multi-Line Telephone Systems (MLTS) and peer to peer VolP service providers. For such users, The SIP URI originating from
EMERGENCY CALLS IN A VOIP SYSTEM
FIELD OF THE INVENTION
In most areas of the world, a unique number is used to make an emergency call.
For North America, this number is "911", and when this number is dialed, the call is automatically routed to a Public Safety Answering Point (PSAP).
In some cases, an emergency call will be dropped, for any number of reasons.
If this occurs, most jurisdictions require that the PSAP be able to call back the person that made the call.
Currently, when a 9-1-1 call is placed by a customer in a VOIP context, a server forwards the call to a 9-1-1 gateway (3rd party call server) which routes the call to the correct Public Safety Answering Point (PSAP) that answers the call. The call delivery is generally done using NENA i1, 12, or i3 standards. The PSAP must be able to call back the caller in case the call is disconnected.
Many VolP users have a Direct Inward Dial (DID) associated with their phone line.
This allows anyone connected to the Public Switch Telephone Network (PSTN) to = call the the VolP user. For such users, the 911 system can obtain the caller's callback number from the SIP signaling messages by reading the SIP URI field.
The field is in the form DIDAprovider.com, where the DID is the VolP user's DID, and the provider.com is the user's domain.
In many cases, it is becoming more common to see VolP phones without assigned DID numbers. This is often the case in Multi-Line Telephone Systems (MLTS) and peer to peer VolP service providers. For such users, The SIP URI originating from
2 call will be a phone extension or an alphanumeric username. Since the phone does not have a direct PSTN callback number that can be reached by the PSAP, these users cannot be adequately serviced.
The traditional solution to this problem is to assign a static phone number to the VolP phone. This solution increases costs to maintain a VolP phone lines and can be complex to administer in large enterprises.
It is required to route the 9-1-1 calls from the different extensions to the correct PSAPs based on the subscriber location and provide this PSAP with a callback number that can call the extension directly without permanently assigning a DID to each extension.
SUMMARY OF THE INVENTION
An object of the invention is to provide a system and method to deliver a callback number for emergency calls in a VOIP system. To achieve this objective, when an extension makes a call, a DID is selected from a pool and bound to it for a finite duration. This DID is used as the callback number to call the phone extension directly. If the PSAP initiates a callback, the call is originated by the 911 service provider, and translated back to the VolP phone's SIP address.
More specifically, according to one aspect of the invention, this object is achieved with a method for delivering callback numbers for emergency calls in a VolP
system, comprising the steps of:
(a) providing a pool of callback numbers consisting of a plurality of individual DIDs;
(b) providing a plurality of IP phones, each phone being provided with a unique SIP URI;
,
The traditional solution to this problem is to assign a static phone number to the VolP phone. This solution increases costs to maintain a VolP phone lines and can be complex to administer in large enterprises.
It is required to route the 9-1-1 calls from the different extensions to the correct PSAPs based on the subscriber location and provide this PSAP with a callback number that can call the extension directly without permanently assigning a DID to each extension.
SUMMARY OF THE INVENTION
An object of the invention is to provide a system and method to deliver a callback number for emergency calls in a VOIP system. To achieve this objective, when an extension makes a call, a DID is selected from a pool and bound to it for a finite duration. This DID is used as the callback number to call the phone extension directly. If the PSAP initiates a callback, the call is originated by the 911 service provider, and translated back to the VolP phone's SIP address.
More specifically, according to one aspect of the invention, this object is achieved with a method for delivering callback numbers for emergency calls in a VolP
system, comprising the steps of:
(a) providing a pool of callback numbers consisting of a plurality of individual DIDs;
(b) providing a plurality of IP phones, each phone being provided with a unique SIP URI;
,
3 (c) at an emergency service provider, temporarily binding a DID to the SIP URI when an emergency call is made from at least one of the phones if the SIP URI is not already bound to a DID; and (d) marking the DID that is bound to the SIP URI as unavailable.
In another aspect, the invention provides a method for delivering callback numbers for emergency calls in a VolP system, comprising temporarily assigning a DID
from a pool of DIDs to a VolP endpoint during a 911 call, the DID mapping a callback number to an IP phone in a VolP system.
In yet another aspect of the invention, there is provided an emergency service provider system, comprising:
a call server for connection to a VolP service provider network;
a subscriber database;
a VPC SBC; and a media gateway for connection to a PSTN;
the call server being adapted to:
receive an emergency call from a VolP telephone in the VolP
network;
verify if the SIP URI has a DID bound to the SIP URI;
if the SIP URI does not have a DID bound to the SIP URI, obtain a temporary DID from a DID pool and temporarily bind the temporary DID to said SIP URI; and forward the call to an appropriate PSAP in the PSTN.
In another aspect of the invention, there is provided a method for delivering callback numbers for emergency calls in a VolP system comprising a VolP
network, said VolP network comprising a VolP switch, the method comprising the steps of:
,
In another aspect, the invention provides a method for delivering callback numbers for emergency calls in a VolP system, comprising temporarily assigning a DID
from a pool of DIDs to a VolP endpoint during a 911 call, the DID mapping a callback number to an IP phone in a VolP system.
In yet another aspect of the invention, there is provided an emergency service provider system, comprising:
a call server for connection to a VolP service provider network;
a subscriber database;
a VPC SBC; and a media gateway for connection to a PSTN;
the call server being adapted to:
receive an emergency call from a VolP telephone in the VolP
network;
verify if the SIP URI has a DID bound to the SIP URI;
if the SIP URI does not have a DID bound to the SIP URI, obtain a temporary DID from a DID pool and temporarily bind the temporary DID to said SIP URI; and forward the call to an appropriate PSAP in the PSTN.
In another aspect of the invention, there is provided a method for delivering callback numbers for emergency calls in a VolP system comprising a VolP
network, said VolP network comprising a VolP switch, the method comprising the steps of:
,
4 (a) providing a pool of callback numbers consisting of a plurality of individual DIDs;
(b) providing a plurality of VolP phones in the VolP network, each phone being provided with a unique SIP URI and being serviced by said VolP
switch and capable of registration with said VolP switch;
(c) assessing when an emergency call is made by one of said VolP
phones;
(d) at an emergency service provider system located outside of the VolP network and communicating with said VolP network via said VolP switch, receiving said SIP URI from said VolP switch and temporarily binding a DID to said SIP URI for a predetermined amount of time when the emergency call is made from at least one of said VolP phones if said SIP URI is not already bound to a DID, wherein said binding is performed outside of and independently of said VolP network; and (e) marking said DID that is bound to said SIP URI as unavailable, wherein said marking is performed outside of said VolP network.
In another aspect of the invention, there is provided a method for delivering callback numbers for emergency calls in a VolP system comprising a VolP
network, said VolP network comprising a VolP switch, the method comprising:
assessing when an emergency call is made by one of a plurality of VolP
phones in said VolP network, each VolP phone being serviced by said VolP switch and capable of registration with said VolP switch;
temporarily assigning, for a predetermined amount of time, a DID from a pool of DIDs to the one of said VolP phones in the VolP network during the emergency call, said DID mapping a callback number to the one of the VolP phones in the VolP network, wherein the pool of DIDs is provided by an emergency service provider system located outside of the VolP network and communicating with said VolP
4a network via said VolP switch, and the assigning is performed outside of and independently of the VolP network; and marking said DID that is bound to said one of the VolP phones as unavailable, wherein said marking is performed outside of said VolP
network.
In another aspect of the invention, there is provided an emergency service provider system for delivering callback numbers for emergency calls in a VolP
system comprising a VolP network, said VolP network comprising a VolP
switch, the emergency service provider system being located outside of the VolP network and communicating with the VolP network via said VolP switch, the emergency service provider system comprising:
a call server for connection to said VolP switch of the VolP network;
a subscriber database;
a VolP Positioning Center (VPC) Session Border Controller (SBC); and a media gateway for connection to a PSTN;
said call server being adapted to:
receive and assess when an emergency call is made from a VolP phone serviced by and capable of registration with said VolP switch in said VolP network, said VolP phone being provided with a unique SIP
URI;
receive the SIP URI from said VolP switch;
verify if the SIP URI has a DID bound to said SIP URI;
if the SIP URI does not have a DID bound to said SIP URI, obtain a temporary DID from a DID pool, temporarily bind said temporary DID
to said SIP URI for a predetermined amount of time, wherein said temporary DID is bound to said SIP URI outside of the VolP
network, and mark said temporary DID that is bound to said SIP URI
4b as unavailable, wherein said marking is performed outside of and independently of said VolP network; and forward the call to an appropriate PSAP in said PSTN.
In another aspect of the invention, there is provided a VolP system comprising:
a VolP network, said VolP network including a VolP switch and a plurality of VolP phones serviced by said VolP switch and capable of registration with said VolP switch, each of the plurality of VolP phones being provided with a unique SIP URI;
an emergency service provider system located outside of the VolP
network and communicating with the VolP network via said VolP switch, said emergency service provider system including:
a call server for connection to said VolP switch of said VolP network;
a subscriber database;
a VolP Positioning Center (VPC) Session Border Controller (SBC); and a media gateway for connection to a PSTN;
said call server being adapted to:
receive and assess when an emergency call is made from a VolP phone in said VolP network;
receive the SIP URI from said VolP switch;
verify if the SIP URI has a DID bound to said SIP URI;
if the SIP URI does not have a DID bound to said SIP URI, obtain a temporary DID from a DID pool, and temporarily bind said temporary DID to said SIP URI for a predetermined amount of time, wherein said temporary DID is bound to said SIP URI outside of and independently of the VolP network, and mark said temporary DID that is bound to said SIP URI as unavailable, wherein said marking is performed outside of said VolP network; and forward the call to an appropriate PSAP in said PSTN.
4c DESCRIPTION OF THE DRAWINGS
The present invention will be better understood after reading a description of a preferred embodiment thereof, made in reference to the following drawings in which:
Figure 1 is a schematic representation of a VolP system according to one embodiment of the present invention; and Figures 2(A) and 2(B) are a sequence diagram of a 911 call, according to a preferred embodiment of the invention.
DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION
VolP E-911 Solution Overview The solution is designed for = VolP service providers that supply enterprises with hosted PBX solutions = VolP service providers that supply enterprises with SIP trunks = VolP service providers that offer peer to peer voice communications (on-net) = VolP service providers that need to offer E911 service to roaming international users without a North American Numbering Plan (NANP).
= Enterprises with single or multiple onsite IP-PBXs = Enterprises with digital VolP gateways connected to legacy PBXs The solution routes 9-1-1 calls to the appropriate Public Safety Answering Point (PSAP) and provides the PSAP with the precise information of the origin of a 9-call. This information includes the phone's exact geographical location and direct callback number.
4d Compliance with FCC and NENA
All enterprises that use VolP telephony must have a 9-1-1 solution in place in order to comply with the FCC's mandate concerning emergency calling. The present invention is fully FCC compliant and follows all approved standards of NENA (The National Emergency Number Association). This ensures full interoperability with the PSAPs, Selective Routers and other infrastructure which makes up the existing emergency services network.
Key Features
(b) providing a plurality of VolP phones in the VolP network, each phone being provided with a unique SIP URI and being serviced by said VolP
switch and capable of registration with said VolP switch;
(c) assessing when an emergency call is made by one of said VolP
phones;
(d) at an emergency service provider system located outside of the VolP network and communicating with said VolP network via said VolP switch, receiving said SIP URI from said VolP switch and temporarily binding a DID to said SIP URI for a predetermined amount of time when the emergency call is made from at least one of said VolP phones if said SIP URI is not already bound to a DID, wherein said binding is performed outside of and independently of said VolP network; and (e) marking said DID that is bound to said SIP URI as unavailable, wherein said marking is performed outside of said VolP network.
In another aspect of the invention, there is provided a method for delivering callback numbers for emergency calls in a VolP system comprising a VolP
network, said VolP network comprising a VolP switch, the method comprising:
assessing when an emergency call is made by one of a plurality of VolP
phones in said VolP network, each VolP phone being serviced by said VolP switch and capable of registration with said VolP switch;
temporarily assigning, for a predetermined amount of time, a DID from a pool of DIDs to the one of said VolP phones in the VolP network during the emergency call, said DID mapping a callback number to the one of the VolP phones in the VolP network, wherein the pool of DIDs is provided by an emergency service provider system located outside of the VolP network and communicating with said VolP
4a network via said VolP switch, and the assigning is performed outside of and independently of the VolP network; and marking said DID that is bound to said one of the VolP phones as unavailable, wherein said marking is performed outside of said VolP
network.
In another aspect of the invention, there is provided an emergency service provider system for delivering callback numbers for emergency calls in a VolP
system comprising a VolP network, said VolP network comprising a VolP
switch, the emergency service provider system being located outside of the VolP network and communicating with the VolP network via said VolP switch, the emergency service provider system comprising:
a call server for connection to said VolP switch of the VolP network;
a subscriber database;
a VolP Positioning Center (VPC) Session Border Controller (SBC); and a media gateway for connection to a PSTN;
said call server being adapted to:
receive and assess when an emergency call is made from a VolP phone serviced by and capable of registration with said VolP switch in said VolP network, said VolP phone being provided with a unique SIP
URI;
receive the SIP URI from said VolP switch;
verify if the SIP URI has a DID bound to said SIP URI;
if the SIP URI does not have a DID bound to said SIP URI, obtain a temporary DID from a DID pool, temporarily bind said temporary DID
to said SIP URI for a predetermined amount of time, wherein said temporary DID is bound to said SIP URI outside of the VolP
network, and mark said temporary DID that is bound to said SIP URI
4b as unavailable, wherein said marking is performed outside of and independently of said VolP network; and forward the call to an appropriate PSAP in said PSTN.
In another aspect of the invention, there is provided a VolP system comprising:
a VolP network, said VolP network including a VolP switch and a plurality of VolP phones serviced by said VolP switch and capable of registration with said VolP switch, each of the plurality of VolP phones being provided with a unique SIP URI;
an emergency service provider system located outside of the VolP
network and communicating with the VolP network via said VolP switch, said emergency service provider system including:
a call server for connection to said VolP switch of said VolP network;
a subscriber database;
a VolP Positioning Center (VPC) Session Border Controller (SBC); and a media gateway for connection to a PSTN;
said call server being adapted to:
receive and assess when an emergency call is made from a VolP phone in said VolP network;
receive the SIP URI from said VolP switch;
verify if the SIP URI has a DID bound to said SIP URI;
if the SIP URI does not have a DID bound to said SIP URI, obtain a temporary DID from a DID pool, and temporarily bind said temporary DID to said SIP URI for a predetermined amount of time, wherein said temporary DID is bound to said SIP URI outside of and independently of the VolP network, and mark said temporary DID that is bound to said SIP URI as unavailable, wherein said marking is performed outside of said VolP network; and forward the call to an appropriate PSAP in said PSTN.
4c DESCRIPTION OF THE DRAWINGS
The present invention will be better understood after reading a description of a preferred embodiment thereof, made in reference to the following drawings in which:
Figure 1 is a schematic representation of a VolP system according to one embodiment of the present invention; and Figures 2(A) and 2(B) are a sequence diagram of a 911 call, according to a preferred embodiment of the invention.
DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION
VolP E-911 Solution Overview The solution is designed for = VolP service providers that supply enterprises with hosted PBX solutions = VolP service providers that supply enterprises with SIP trunks = VolP service providers that offer peer to peer voice communications (on-net) = VolP service providers that need to offer E911 service to roaming international users without a North American Numbering Plan (NANP).
= Enterprises with single or multiple onsite IP-PBXs = Enterprises with digital VolP gateways connected to legacy PBXs The solution routes 9-1-1 calls to the appropriate Public Safety Answering Point (PSAP) and provides the PSAP with the precise information of the origin of a 9-call. This information includes the phone's exact geographical location and direct callback number.
4d Compliance with FCC and NENA
All enterprises that use VolP telephony must have a 9-1-1 solution in place in order to comply with the FCC's mandate concerning emergency calling. The present invention is fully FCC compliant and follows all approved standards of NENA (The National Emergency Number Association). This ensures full interoperability with the PSAPs, Selective Routers and other infrastructure which makes up the existing emergency services network.
Key Features
5 Temporary binding of a DID number to a VolP endpoint By temporarily assigning a DID to a VolP endpoint during a 911 call, the present invention makes it possible for a PSAP to directly call back the phone in case of a dropped 9-1-1 call. This unique feature offers the following significant benefits:
= For enterprises, it ensures that dispatchers can quickly reach the person that made the emergency call without having to go through an intervening IVR system or receptionist.
= For enterprises, it eliminates the need to assign and manage emergency location identifier numbers (ELINs) to each phone.
= For users without a DID or not using a 10 digit North American Numbering Plan (NANP), a DID can be displayed at the PSAP control screen and used to call back the user.
Deployment Diagram The following sections describe generally the deployment diagram for the invention. Figure 1 shows the various components of the system according to a preferred embodiment of the invention, and are described hereinafter.
IP Phone The solution supports any type of IP phone. The phone's location must be pre-registered in the 911 Service provider database, or obtained from a local LIS.
An IP phone is identified by a unique endpoint identifier. Examples of an endpoint identifier can be a phone number, an extension number, or a MAC address.
= For enterprises, it ensures that dispatchers can quickly reach the person that made the emergency call without having to go through an intervening IVR system or receptionist.
= For enterprises, it eliminates the need to assign and manage emergency location identifier numbers (ELINs) to each phone.
= For users without a DID or not using a 10 digit North American Numbering Plan (NANP), a DID can be displayed at the PSAP control screen and used to call back the user.
Deployment Diagram The following sections describe generally the deployment diagram for the invention. Figure 1 shows the various components of the system according to a preferred embodiment of the invention, and are described hereinafter.
IP Phone The solution supports any type of IP phone. The phone's location must be pre-registered in the 911 Service provider database, or obtained from a local LIS.
An IP phone is identified by a unique endpoint identifier. Examples of an endpoint identifier can be a phone number, an extension number, or a MAC address.
6 Softphone A softphone is an IP phone running as software on a PC or handheld device. The phone's location must be pre-registered in the 911 Service provider database, or obtained from a local LIS. A softphone is identified by a unique endpoint identifier.
Examples of an endpoint identifier can be a phone number, an extension number, or a MAC address.
Local Location Information Server (LIS) A local LIS maintains the IP phone or softphone location information.
Generally, the local LIS has location acquisition technology, such as crawling layer 2 switches to detect phones and their location. The local LIS is an optional component in the solution of the present invention.
1P-PBX or Softswitch The IP-PBX or Softswitch is used to deliver the calls to the 911 service provider.
The 911 calls can be delivered using standard VolP protocols such as SIP and RTP. The equipment must deliver the caller's endpoint identifier, originating address (i.e. SIP address), and can optionally include a location object (PIDF-LO).
The IP-PBX must be able to ring the caller's endpoint when the call is destined to the phone's address (i.e. ext 5150@acme.com must ring extension 5150).
Ca// Server The 911 provider receives 911 calls on their call servers. Call servers are generally session border controllers (SBC) that support the VolP protocols interfacing with the IP-PBX and softswitches. The call server is responsible to setup call. It obtains an available DID from the DID pool, looks up the customer location in the subscriber database, and routes the call to the VPC/Gateways using standard i2 call signaling.
Examples of an endpoint identifier can be a phone number, an extension number, or a MAC address.
Local Location Information Server (LIS) A local LIS maintains the IP phone or softphone location information.
Generally, the local LIS has location acquisition technology, such as crawling layer 2 switches to detect phones and their location. The local LIS is an optional component in the solution of the present invention.
1P-PBX or Softswitch The IP-PBX or Softswitch is used to deliver the calls to the 911 service provider.
The 911 calls can be delivered using standard VolP protocols such as SIP and RTP. The equipment must deliver the caller's endpoint identifier, originating address (i.e. SIP address), and can optionally include a location object (PIDF-LO).
The IP-PBX must be able to ring the caller's endpoint when the call is destined to the phone's address (i.e. ext 5150@acme.com must ring extension 5150).
Ca// Server The 911 provider receives 911 calls on their call servers. Call servers are generally session border controllers (SBC) that support the VolP protocols interfacing with the IP-PBX and softswitches. The call server is responsible to setup call. It obtains an available DID from the DID pool, looks up the customer location in the subscriber database, and routes the call to the VPC/Gateways using standard i2 call signaling.
7 DID Pool The DID pool is a database of 10 digit NANP numbers from various markets. The pool is shared with all customers. When a 911 call is made, any free DID is assigned to the endpoint for a finite period before it is released back into the pool.
The DID is assigned to the user populated in the ALI display as the callback number field. The DID pool maintains the associations of the DID to endpoints, allowing the call server to easily map from one to the other.
Subscriber database The subscriber database maintains the data related to emergency responder locations (ERL) and endpoints associated to these ERLs. The subscriber database is not used if the endpoint is able to deliver its location information in a location object (PIDF-LO). Generally, the subscriber database is updated either through a web interface, or by a local LIS.
VPC SBC
The VolP Positioning Center (VPC) Session Border Controller (SBC) corresponds to the SIP proxy server described in the NENA 12 standard VPC
The VolP Positioning Center (VPC) performs the functions described in the NENA
i2 standard ERDB
The Emergency Routing Database (ERDB) performs the functions described in the NENA 12 standard LIS
The Location Information Server (LIS) performs the functions described in the NENA i2 standard
The DID is assigned to the user populated in the ALI display as the callback number field. The DID pool maintains the associations of the DID to endpoints, allowing the call server to easily map from one to the other.
Subscriber database The subscriber database maintains the data related to emergency responder locations (ERL) and endpoints associated to these ERLs. The subscriber database is not used if the endpoint is able to deliver its location information in a location object (PIDF-LO). Generally, the subscriber database is updated either through a web interface, or by a local LIS.
VPC SBC
The VolP Positioning Center (VPC) Session Border Controller (SBC) corresponds to the SIP proxy server described in the NENA 12 standard VPC
The VolP Positioning Center (VPC) performs the functions described in the NENA
i2 standard ERDB
The Emergency Routing Database (ERDB) performs the functions described in the NENA 12 standard LIS
The Location Information Server (LIS) performs the functions described in the NENA i2 standard
8 Media Gateway The Media Gateway interfaces between the IP and the PSTN networks. It performs the functions of an emergency services gateway (ESGW) described n the NENA 12 standard. The Media gateway also handles PSAP callbacks and routes them to the call server for processing.
Selective Router:
The selective router is managed by the Local Exchange Carrier (LEC) and is used to route 911 calls to the appropriate PSAP based on the Emergency Services Number (ESN).
PSAP
The Public Safety Answering Point (PSAP) is staffed by trained professionals to answer emergency 911 calls. The PSAP has access to an automatic location information database (ALI) to retrieve the caller's address and callback number.
ALI
The automatic location information database (ALI) contains a list of phone numbers and corresponding locations. For VolP users, the ALI only holds a shell record that points to the VPC ALI-Link. When a 911 call is received the ALI
queries the VPC to obtain a caller's record.
1. Overview The solution according to an embodiment of the present invention is applicable in the following cases:
= VolP service providers that supply enterprises with hosted IP-PBX
solutions = VolP service providers that supply enterprises with SIP trunks = Enterprises with single or multiple onsite IP-PBXs
Selective Router:
The selective router is managed by the Local Exchange Carrier (LEC) and is used to route 911 calls to the appropriate PSAP based on the Emergency Services Number (ESN).
PSAP
The Public Safety Answering Point (PSAP) is staffed by trained professionals to answer emergency 911 calls. The PSAP has access to an automatic location information database (ALI) to retrieve the caller's address and callback number.
ALI
The automatic location information database (ALI) contains a list of phone numbers and corresponding locations. For VolP users, the ALI only holds a shell record that points to the VPC ALI-Link. When a 911 call is received the ALI
queries the VPC to obtain a caller's record.
1. Overview The solution according to an embodiment of the present invention is applicable in the following cases:
= VolP service providers that supply enterprises with hosted IP-PBX
solutions = VolP service providers that supply enterprises with SIP trunks = Enterprises with single or multiple onsite IP-PBXs
9 = Peer to Peer VolP Service providers that do not assign DIDs to each account.
= VolP Service providers that offer service to international users without assigning them to a North American Numbering plan.
An enterprise customer is defined as an entity that uses a VolP PBX and requires E911 service for each of their extensions. Some enterprise customers will only have one office location. Others will have multiple office locations. In many cases, these extensions will not have DIDs assigned to them.
" A VolP service provider (VSP) is defines as an entity that provides VolP calling service and requires E911 service for each customer.
Enhanced 911 services are provided by routing 9-1-1 calls using the NENA i2 standard to the appropriate Public Safety Answering Point (PSAP). This method provides the PSAP of the caller's precise location and callback number during the call setup. This information includes the phone exact geographical location and callback number.
Without the present invention, the PSAP is unable to call the distressed caller if it does not have a callback number. MTLS solutions offer certain workarounds to do this:
= Some MTLS systems map phone extensions to a main number. However, the callback number rings the company IVR or receptionist, wasting valuable time for the dispatchers trying to reach the person that made the emergency call.
= Some MTLS systems map Emergency Location Identification Numbers (ELINs) to each location. This is done by assigning a permanent DID for each emergency responder location (ERL) such as a floor, wing, or suite.
This requires the MTLS administrator to purchase DIDs for each location and ensure that the system maps the extension to the correct DID based on the caller's location. This is highly impractical for MTLS systems that have users in many dispersed locations, particularly for work at home employees, and traveling workers.
By temporarily binding a DID to an VolP phone during a 911 call, the invention makes it possible for a PSAP to directly call back the extension in case of a dropped 9-1-1 call while reducing costs and administration efforts. This is possible even thought the extension does not have a permanently bound DID.
2. Configuration This section describes the configuration parameters required to enable this feature, according to an embodiment of the present invention.
2.1 Emergency Responder Location A caller's Emergency Responder Location (ERL) must be provisioned in a location identifier server (LIS). The ERL data consists of a valid civic address that can be matched to a PSAP Master Street Address Guide (MSAG) record and additional location information such as floor, suite, cubicle data. An ERL is identified and indexed by the Location Key (LK).
2.2 SIP URI mapping table Each enterprise extension is associated to a location. This grouping is configured in the softswitch. The softswitch has a SIP URI mapping table that can remap the phone's SIP URI to the SIP URI of the location key (LK) for 9-1-1 calls. SIP
URIs are unique across the system.
2.3 E911 DID pool The softswitch is configured with a list of DIDs that can be dynamically bound to a SIP URIs during the 911 call setup process. These DIDs must be obtained from a local carrier, but can be shared among a large number of users since the occurrence of 911 calls is very low.
2.4 911 Call rules Each trunk (or resource) must be configured with rules that allow it to process 9-1-1 calls.
The rule will normally be applied to calls that dial 9-1-1 and arrive from IP
addresses that are registered as 911Enable clients.
If the call matches the 9-1-1 rule, the following actions must be taken:
- Bind a DID from the E911 DID Pool to the SIP URI (if not already bound to a DID.) - Insert the corresponding DID in the P-Asserted-Identity as a TEL
URI.
- Remap the caller's SIP URI to a location key (LK) For example, a 9-1-1 call from SIP URI 02123456john@company X is placed. The 911 call rule will bound to +12121234567, put the DID in the P-Asserted-Identity and replace the SIP URI with locationx@911provider.com.
2.5 DID Binding Duration The DID binding duration is configurable for each trunk. The default value with be 48 hours.
3. Sequence Diagrams 3.1 Normal E-911 call scenario with Emergency Callback A normal E-911 call scenario with Emergency Callback is illustrated in Figures 2(A) and 2(B), and follows the sequence outlined below.
Sequence Description Number 1 The phone with an endpoint identifier of 250 (i.e. extension 250) makes a 911 call.
2 The IP-PBX/Softswitch is configured to forward the call to the 911 Call Server. The softswitch converts the call to the appropriate protocol (i.e. SIP/RTP) and sets the SIP URI from field to 250@domain.com 3 911Enable session controller receives the call and requests an available DID from the DID Pool Database.
4 DID Pool Database returns an available DID that is not bound to another user.
5 911 Call Server inserts the dynamically assigned DID in the P-Asserted-Identity field as a TEL URI, and remaps the FROM SIP URI
from the endpoint address, to the caller's location key locationa(911enable.com. The call is forwarded to the NENA i2 infrastructure A person skilled in the art will readily recognize that the NENA interim 2 standard for detailed call flows between the various components is applicable.
12a 6 The call is forwarded to the appropriate PSAP using NENA i2 call signaling. PSAP queries the ALI database to retrieve receives the subscriber information and the callback number to call the extension directly. The callback number is the dynamically assigned DID from the DID pool.
7 Voice communication is established.
8 Call hangs up normally using standard SIP signaling.
9 PSAP attempts to callback the user based on the callback number provided in the original call (5141234567). Carrier forwards call to the 911 call server.
The 911 Call Server remaps the dynamic DID (5141234567) to the endpoint's SIP address.
11 The IP-PBX/Sofswitch uses the endpoint's SIP address to forward the call to the appropriate phone.
12 Call is re-established between the 9-1-1 caller extension and the PSAP. When the conversation is completed, the call hangs up normally using standard SIP signaling.
13 After the configured binding time, the DID is released and put back into the pool of available DIDs 3.2 E911 call made form the same extension in 48 hours Since the SIP URI is already bound to the DID, the DID will be reused for the call 5 and the 48 hour timer is reset. Otherwise this case is handled exactly the same way as described in sequence 3.1 Normal E-911 call scenario with Emergency Callback The following is a list of acronyms used in the description of the present invention,
= VolP Service providers that offer service to international users without assigning them to a North American Numbering plan.
An enterprise customer is defined as an entity that uses a VolP PBX and requires E911 service for each of their extensions. Some enterprise customers will only have one office location. Others will have multiple office locations. In many cases, these extensions will not have DIDs assigned to them.
" A VolP service provider (VSP) is defines as an entity that provides VolP calling service and requires E911 service for each customer.
Enhanced 911 services are provided by routing 9-1-1 calls using the NENA i2 standard to the appropriate Public Safety Answering Point (PSAP). This method provides the PSAP of the caller's precise location and callback number during the call setup. This information includes the phone exact geographical location and callback number.
Without the present invention, the PSAP is unable to call the distressed caller if it does not have a callback number. MTLS solutions offer certain workarounds to do this:
= Some MTLS systems map phone extensions to a main number. However, the callback number rings the company IVR or receptionist, wasting valuable time for the dispatchers trying to reach the person that made the emergency call.
= Some MTLS systems map Emergency Location Identification Numbers (ELINs) to each location. This is done by assigning a permanent DID for each emergency responder location (ERL) such as a floor, wing, or suite.
This requires the MTLS administrator to purchase DIDs for each location and ensure that the system maps the extension to the correct DID based on the caller's location. This is highly impractical for MTLS systems that have users in many dispersed locations, particularly for work at home employees, and traveling workers.
By temporarily binding a DID to an VolP phone during a 911 call, the invention makes it possible for a PSAP to directly call back the extension in case of a dropped 9-1-1 call while reducing costs and administration efforts. This is possible even thought the extension does not have a permanently bound DID.
2. Configuration This section describes the configuration parameters required to enable this feature, according to an embodiment of the present invention.
2.1 Emergency Responder Location A caller's Emergency Responder Location (ERL) must be provisioned in a location identifier server (LIS). The ERL data consists of a valid civic address that can be matched to a PSAP Master Street Address Guide (MSAG) record and additional location information such as floor, suite, cubicle data. An ERL is identified and indexed by the Location Key (LK).
2.2 SIP URI mapping table Each enterprise extension is associated to a location. This grouping is configured in the softswitch. The softswitch has a SIP URI mapping table that can remap the phone's SIP URI to the SIP URI of the location key (LK) for 9-1-1 calls. SIP
URIs are unique across the system.
2.3 E911 DID pool The softswitch is configured with a list of DIDs that can be dynamically bound to a SIP URIs during the 911 call setup process. These DIDs must be obtained from a local carrier, but can be shared among a large number of users since the occurrence of 911 calls is very low.
2.4 911 Call rules Each trunk (or resource) must be configured with rules that allow it to process 9-1-1 calls.
The rule will normally be applied to calls that dial 9-1-1 and arrive from IP
addresses that are registered as 911Enable clients.
If the call matches the 9-1-1 rule, the following actions must be taken:
- Bind a DID from the E911 DID Pool to the SIP URI (if not already bound to a DID.) - Insert the corresponding DID in the P-Asserted-Identity as a TEL
URI.
- Remap the caller's SIP URI to a location key (LK) For example, a 9-1-1 call from SIP URI 02123456john@company X is placed. The 911 call rule will bound to +12121234567, put the DID in the P-Asserted-Identity and replace the SIP URI with locationx@911provider.com.
2.5 DID Binding Duration The DID binding duration is configurable for each trunk. The default value with be 48 hours.
3. Sequence Diagrams 3.1 Normal E-911 call scenario with Emergency Callback A normal E-911 call scenario with Emergency Callback is illustrated in Figures 2(A) and 2(B), and follows the sequence outlined below.
Sequence Description Number 1 The phone with an endpoint identifier of 250 (i.e. extension 250) makes a 911 call.
2 The IP-PBX/Softswitch is configured to forward the call to the 911 Call Server. The softswitch converts the call to the appropriate protocol (i.e. SIP/RTP) and sets the SIP URI from field to 250@domain.com 3 911Enable session controller receives the call and requests an available DID from the DID Pool Database.
4 DID Pool Database returns an available DID that is not bound to another user.
5 911 Call Server inserts the dynamically assigned DID in the P-Asserted-Identity field as a TEL URI, and remaps the FROM SIP URI
from the endpoint address, to the caller's location key locationa(911enable.com. The call is forwarded to the NENA i2 infrastructure A person skilled in the art will readily recognize that the NENA interim 2 standard for detailed call flows between the various components is applicable.
12a 6 The call is forwarded to the appropriate PSAP using NENA i2 call signaling. PSAP queries the ALI database to retrieve receives the subscriber information and the callback number to call the extension directly. The callback number is the dynamically assigned DID from the DID pool.
7 Voice communication is established.
8 Call hangs up normally using standard SIP signaling.
9 PSAP attempts to callback the user based on the callback number provided in the original call (5141234567). Carrier forwards call to the 911 call server.
The 911 Call Server remaps the dynamic DID (5141234567) to the endpoint's SIP address.
11 The IP-PBX/Sofswitch uses the endpoint's SIP address to forward the call to the appropriate phone.
12 Call is re-established between the 9-1-1 caller extension and the PSAP. When the conversation is completed, the call hangs up normally using standard SIP signaling.
13 After the configured binding time, the DID is released and put back into the pool of available DIDs 3.2 E911 call made form the same extension in 48 hours Since the SIP URI is already bound to the DID, the DID will be reused for the call 5 and the 48 hour timer is reset. Otherwise this case is handled exactly the same way as described in sequence 3.1 Normal E-911 call scenario with Emergency Callback The following is a list of acronyms used in the description of the present invention,
10 and are reproduced for the reader's convenience, although persons skilled in the art will recognize the significance of these acronyms.
Acronyms:
DID
Direct Inward Dialing: The number assigned to a VolP user that allows that user to connect to the old PSTN Networks around the world.
-Enhanced 911: E911 services connect VolP services to the existing 911 infrastructure. This allows for a VolP emergency call to provide the same emergency-relevant location information that traditional telephony provides.
PSTN
Public Switched Telephone Network: The world's public circuit-switched telephone networks. The PSTN is largely governed by technical standards created by the International Telecommunication Union.
SIP
Session Initiation Protocol: A protocol and standard for initiating, modifying, and terminating a multimedia (voice, video, etc) interactive session. SIP was accepted in 2000 as the 3GPP signaling element and a permanent element of IMS
architecture.
URI
(Uniform Resource Identifier) The address of an Internet resource. A URI is the unique name used to access the resource. It is not necessarily a specific file location (it may be a call to an application or a database, for example), which is why it is preferred over the similar acronym URL (Uniform Resource Locator).
Although the present invention has been explained hereinabove by way of a preferred embodiment thereof, it should be pointed out that any modifications to this preferred embodiment within the scope of the appended claims is not deemed to alter or change the nature and scope of the present invention.
Acronyms:
DID
Direct Inward Dialing: The number assigned to a VolP user that allows that user to connect to the old PSTN Networks around the world.
-Enhanced 911: E911 services connect VolP services to the existing 911 infrastructure. This allows for a VolP emergency call to provide the same emergency-relevant location information that traditional telephony provides.
PSTN
Public Switched Telephone Network: The world's public circuit-switched telephone networks. The PSTN is largely governed by technical standards created by the International Telecommunication Union.
SIP
Session Initiation Protocol: A protocol and standard for initiating, modifying, and terminating a multimedia (voice, video, etc) interactive session. SIP was accepted in 2000 as the 3GPP signaling element and a permanent element of IMS
architecture.
URI
(Uniform Resource Identifier) The address of an Internet resource. A URI is the unique name used to access the resource. It is not necessarily a specific file location (it may be a call to an application or a database, for example), which is why it is preferred over the similar acronym URL (Uniform Resource Locator).
Although the present invention has been explained hereinabove by way of a preferred embodiment thereof, it should be pointed out that any modifications to this preferred embodiment within the scope of the appended claims is not deemed to alter or change the nature and scope of the present invention.
Claims (9)
1. A method for delivering callback numbers for emergency calls in a VolP
system comprising a VolP network, said VolP network comprising a VolP switch, the method comprising the steps of:
(a) providing a pool of callback numbers consisting of a plurality of individual DIDs;
(b) providing a plurality of VoIP phones in the VolP network, each phone being provided with a unique SIP URI and being serviced by said VolP switch and capable of registration with said VolP switch;
(c) assessing when an emergency call is made by one of said VolP
phones;
(d) at an emergency service provider system located outside of the VolP
network and communicating with said VolP network via said VolP switch, receiving said SIP URI from said VolP switch and temporarily binding a DID to said SIP URI for a predetermined amount of time when the emergency call is made from at least one of said VolP phones if said SIP URI is not already bound to a DID, wherein said binding is performed outside of and independently of said VolP network; and (e) marking said DID that is bound to said SIP URI as unavailable, wherein said marking is performed outside of said VolP network.
system comprising a VolP network, said VolP network comprising a VolP switch, the method comprising the steps of:
(a) providing a pool of callback numbers consisting of a plurality of individual DIDs;
(b) providing a plurality of VoIP phones in the VolP network, each phone being provided with a unique SIP URI and being serviced by said VolP switch and capable of registration with said VolP switch;
(c) assessing when an emergency call is made by one of said VolP
phones;
(d) at an emergency service provider system located outside of the VolP
network and communicating with said VolP network via said VolP switch, receiving said SIP URI from said VolP switch and temporarily binding a DID to said SIP URI for a predetermined amount of time when the emergency call is made from at least one of said VolP phones if said SIP URI is not already bound to a DID, wherein said binding is performed outside of and independently of said VolP network; and (e) marking said DID that is bound to said SIP URI as unavailable, wherein said marking is performed outside of said VolP network.
2. A method according to claim 1, wherein said DID is bound to said SIP URI
for up to 48 hours, and is subsequently marked as available in said pool of callback numbers.
for up to 48 hours, and is subsequently marked as available in said pool of callback numbers.
3. A method according to claim 1 or 2, wherein said emergency service provider system is a 911 service provider system.
4. A method for delivering callback numbers for emergency calls in a VolP
system comprising a VolP network, said VolP network comprising a VolP switch, the method comprising:
assessing when an emergency call is made by one of a plurality of VolP
phones in said VolP network, each VolP phone being serviced by said VolP switch and capable of registration with said VolP switch;
temporarily assigning, for a predetermined amount of time, a DID from a pool of DIDs to the one of said VolP phones in the VolP network during the emergency call, said DID mapping a callback number to the one of the VolP phones in the VolP network, wherein the pool of DIDs is provided by an emergency service provider system located outside of the VolP network and communicating with said VolP network via said VolP switch, and the assigning is performed outside of and independently of the VolP network; and marking said DID that is bound to said one of the VolP phones as unavailable, wherein said marking is performed outside of said VolP
network.
system comprising a VolP network, said VolP network comprising a VolP switch, the method comprising:
assessing when an emergency call is made by one of a plurality of VolP
phones in said VolP network, each VolP phone being serviced by said VolP switch and capable of registration with said VolP switch;
temporarily assigning, for a predetermined amount of time, a DID from a pool of DIDs to the one of said VolP phones in the VolP network during the emergency call, said DID mapping a callback number to the one of the VolP phones in the VolP network, wherein the pool of DIDs is provided by an emergency service provider system located outside of the VolP network and communicating with said VolP network via said VolP switch, and the assigning is performed outside of and independently of the VolP network; and marking said DID that is bound to said one of the VolP phones as unavailable, wherein said marking is performed outside of said VolP
network.
5. An emergency service provider system for delivering callback numbers for emergency calls in a VolP system comprising a VolP network, said VolP network comprising a VolP switch, the emergency service provider system being located outside of the VolP network and communicating with the VolP network via said VolP switch, the emergency service provider system comprising:
a call server for connection to said VolP switch of the VolP network;
a subscriber database;
a VolP Positioning Center (VPC) Session Border Controller (SBC); and a media gateway for connection to a PSTN;
said call server being adapted to:
receive and assess when an emergency call is made from a VolP phone serviced by and capable of registration with said VolP switch in said VolP network, said VolP phone being provided with a unique SIP URI;
receive the SIP URI from said VoIP switch;
verify if the SIP URI has a DID bound to said SIP URI;
if the SIP URI does not have a DID bound to said SIP URI, obtain a temporary DID from a DID pool, temporarily bind said temporary DID to said SIP URI for a predetermined amount of time, wherein said temporary DID is bound to said SIP URI outside of the VolP network, and mark said temporary DID that is bound to said SIP URI as unavailable, wherein said marking is performed outside of and independently of said VolP network; and forward the call to an appropriate PSAP in said PSTN.
a call server for connection to said VolP switch of the VolP network;
a subscriber database;
a VolP Positioning Center (VPC) Session Border Controller (SBC); and a media gateway for connection to a PSTN;
said call server being adapted to:
receive and assess when an emergency call is made from a VolP phone serviced by and capable of registration with said VolP switch in said VolP network, said VolP phone being provided with a unique SIP URI;
receive the SIP URI from said VoIP switch;
verify if the SIP URI has a DID bound to said SIP URI;
if the SIP URI does not have a DID bound to said SIP URI, obtain a temporary DID from a DID pool, temporarily bind said temporary DID to said SIP URI for a predetermined amount of time, wherein said temporary DID is bound to said SIP URI outside of the VolP network, and mark said temporary DID that is bound to said SIP URI as unavailable, wherein said marking is performed outside of and independently of said VolP network; and forward the call to an appropriate PSAP in said PSTN.
6. An emergency service provider system according to claim 5, wherein said emergency service provider system is a 911 service provider system.
7. An emergency service provider system according to claim 5 or 6, wherein said temporary DID is bound to said SIP URI for a period of up to 48 hours.
8. A VoIP system comprising:
a VoIP network, said VolP network including a VolP switch and a plurality of VolP phones serviced by said VolP switch and capable of registration with said VolP switch, each of the plurality of VoIP phones being provided with a unique SIP URI;
an emergency service provider system located outside of the VolP network and communicating with the VolP network via said VolP switch, said emergency service provider system including:
a call server for connection to said VolP switch of said VolP network;
a subscriber database;
a VolP Positioning Center (VPC) Session Border Controller (SBC); and a media gateway for connection to a PSTN;
said call server being adapted to:
receive and assess when an emergency call is made from a VolP phone in said VolP network;
receive the SIP URI from said VolP switch;
verify if the SIP URI has a DID bound to said SIP URI;
if the SIP URI does not have a DID bound to said SIP URI, obtain a temporary DID from a DID pool, and temporarily bind said temporary DID to said SIP URI for a predetermined amount of time, wherein said temporary DID is bound to said SIP URI outside of and independently of the VolP network, and mark said temporary DID that is bound to said SIP URI as unavailable, wherein said marking is performed outside of said VolP network; and forward the call to an appropriate PSAP in said PSTN.
a VoIP network, said VolP network including a VolP switch and a plurality of VolP phones serviced by said VolP switch and capable of registration with said VolP switch, each of the plurality of VoIP phones being provided with a unique SIP URI;
an emergency service provider system located outside of the VolP network and communicating with the VolP network via said VolP switch, said emergency service provider system including:
a call server for connection to said VolP switch of said VolP network;
a subscriber database;
a VolP Positioning Center (VPC) Session Border Controller (SBC); and a media gateway for connection to a PSTN;
said call server being adapted to:
receive and assess when an emergency call is made from a VolP phone in said VolP network;
receive the SIP URI from said VolP switch;
verify if the SIP URI has a DID bound to said SIP URI;
if the SIP URI does not have a DID bound to said SIP URI, obtain a temporary DID from a DID pool, and temporarily bind said temporary DID to said SIP URI for a predetermined amount of time, wherein said temporary DID is bound to said SIP URI outside of and independently of the VolP network, and mark said temporary DID that is bound to said SIP URI as unavailable, wherein said marking is performed outside of said VolP network; and forward the call to an appropriate PSAP in said PSTN.
9.
A system according to claim 8, wherein at least one of said plurality of VolP
phones is a softphone.
A system according to claim 8, wherein at least one of said plurality of VolP
phones is a softphone.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US83886806P | 2006-08-21 | 2006-08-21 | |
US60/838,868 | 2006-08-21 |
Publications (2)
Publication Number | Publication Date |
---|---|
CA2598200A1 CA2598200A1 (en) | 2008-02-21 |
CA2598200C true CA2598200C (en) | 2015-10-27 |
Family
ID=39103154
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA2598200A Expired - Fee Related CA2598200C (en) | 2006-08-21 | 2007-08-21 | System and method for delivering callback numbers for emergency calls in a voip system |
Country Status (1)
Country | Link |
---|---|
CA (1) | CA2598200C (en) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DK2084868T3 (en) | 2006-11-02 | 2018-09-03 | Voip Pal Com Inc | MAKING ROUTING MESSAGES FOR VOICE-OVER IP COMMUNICATION |
BRPI0719682B1 (en) | 2006-11-29 | 2020-11-24 | Voip-Pal.Com, Inc. | INTERCEPTING VOICE COMMUNICATIONS VIA IP AND OTHER DATA COMMUNICATIONS |
WO2008116296A1 (en) | 2007-03-26 | 2008-10-02 | Digifonica (International) Limited | Emergency assistance calling for voice over ip communications systems |
EP2311292B1 (en) | 2008-07-28 | 2020-12-16 | Voip-Pal.Com, Inc. | Mobile gateway |
EP2478678B1 (en) | 2009-09-17 | 2016-01-27 | Digifonica (International) Limited | Uninterrupted transmission of internet protocol transmissions during endpoint changes |
-
2007
- 2007-08-21 CA CA2598200A patent/CA2598200C/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
CA2598200A1 (en) | 2008-02-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8774370B2 (en) | System and method for delivering callback numbers for emergency calls in a VOIP system | |
US7907551B2 (en) | Voice over internet protocol (VoIP) location based 911 conferencing | |
US7627091B2 (en) | Universal emergency number ELIN based on network address ranges | |
US8520805B2 (en) | Video E911 | |
US9426304B2 (en) | Answering or releasing emergency calls from a map display for an emergency services platform | |
US8903355B2 (en) | Answering or releasing emergency calls from a map display for an emergency services platform | |
JP4922952B2 (en) | System and method for providing 911 service to a mobile internet telephone caller | |
US8824454B2 (en) | Peering network for parameter-based routing of special number calls | |
US20070003024A1 (en) | Network emergency call taking system and method | |
CA2712420C (en) | Method and apparatus for emergency services number alerting in an internet protocol network | |
US20070121798A1 (en) | Public service answering point (PSAP) proxy | |
US7894406B2 (en) | System for routing remote VoIP emergency calls | |
US7127044B1 (en) | Pooling numbers for E911 calls from unnamed endpoints | |
CA2598200C (en) | System and method for delivering callback numbers for emergency calls in a voip system | |
KR20070097523A (en) | Personalized calling name identification in telecommunication networks | |
US8351593B2 (en) | Emergency recording during VoIP session | |
US7319692B2 (en) | Subscriber mobility in telephony systems | |
US7734021B1 (en) | Method and apparatus for supporting out of area phone number for emergency services | |
WO2007044454A2 (en) | Voice over internet protocol (voip) location based 911 conferencing | |
US7590107B2 (en) | TCP/IP transport interface for ISDN telephone | |
Jeong et al. | Design for supporting the multimedia emergency VoIP using PSTN and IP network |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
MKLA | Lapsed |
Effective date: 20200831 |