Language selection

Search

Patent 2598200 Summary

Third-party information liability

Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.

Claims and Abstract availability

Any discrepancies in the text and image of the Claims and Abstract are due to differing posting times. Text of the Claims and Abstract are posted:

  • At the time the application is open to public inspection;
  • At the time of issue of the patent (grant).
(12) Patent: (11) CA 2598200
(54) English Title: SYSTEM AND METHOD FOR DELIVERING CALLBACK NUMBERS FOR EMERGENCY CALLS IN A VOIP SYSTEM
(54) French Title: SYSTEME ET METHODE DE LIVRAISON DE NUMEROS DE RAPPEL AUTOMATIQUE POUR APPELS D'URGENCE D'UN RESEAU VOIP
Status: Expired and beyond the Period of Reversal
Bibliographic Data
(51) International Patent Classification (IPC):
  • H04L 12/66 (2006.01)
  • H04M 3/42 (2006.01)
  • H04M 11/06 (2006.01)
  • H04Q 3/00 (2006.01)
  • H04Q 3/64 (2006.01)
(72) Inventors :
  • KRIVOROT, AVI (Canada)
  • KRIVOROT, ZOHAR (Canada)
  • DEICH, LEV (Canada)
(73) Owners :
  • INTRADO INC.
(71) Applicants :
  • INTRADO INC. (United States of America)
(74) Agent: ROBIC AGENCE PI S.E.C./ROBIC IP AGENCY LP
(74) Associate agent:
(45) Issued: 2015-10-27
(22) Filed Date: 2007-08-21
(41) Open to Public Inspection: 2008-02-21
Examination requested: 2012-06-05
Availability of licence: N/A
Dedicated to the Public: N/A
(25) Language of filing: English

Patent Cooperation Treaty (PCT): No

(30) Application Priority Data:
Application No. Country/Territory Date
60/838,868 (United States of America) 2006-08-21

Abstracts

English 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.


French Abstract

Dans un système VoIP, une méthode et un appareil pour suivre des appels durgence sont décrits. Un réseau de fournisseur de services VoIP comprend une pluralité de téléphones VoIP et est connecté à un système de fournisseur de services durgence. Le système de fournisseur de services durgence comprend un serveur dappel connecté à un réseau de fournisseur de services VoIP; une base de données dabonnés; un SBC de PCV; et une passerelle média pour une connexion à un RTCP. Le serveur dappel est conçu pour recevoir un appel durgence dun téléphone VoIP dans le réseau VoIP; vérifier si le SIP URI possède une SDA liée au SIP URI; si le SIP URI ne possède pas une SDA liée au SIP URI, obtenir une SDA temporaire à partir dun groupe de SDA et temporairement lier la SDA temporaire audit SIP URI; et faire suivre lappel à un CTSP dans le RTCP. Si lappel durgence est interrompu, une personne au CTSP peut rappeler lappelant durgence sans retard inutile.

Claims

Note: Claims are shown in the official language in which they were submitted.


15
WHAT IS CLAIMED IS:
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.
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.
3. A method according to claim 1 or 2, wherein said emergency service
provider system is a 911 service provider system.

16
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.
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;

17
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:

18
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.

Description

Note: Descriptions are shown in the official language in which they were submitted.


CA 02598200 2007-08-21
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

CA 02598200 2007-08-21
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;

CA 02598200 2014-09-16
,
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:

CA 02598200 2014-09-16
,
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

CA 02598200 2014-09-16
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

CA 02598200 2014-09-16
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.

CA 02598200 2014-09-16
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-
1-1
call. This information includes the phone's exact geographical location and
direct
callback number.

CA 02598200 2014-09-16
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

CA 02598200 2007-08-21
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.

CA 02598200 2007-08-21
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.

CA 02598200 2007-08-21
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

CA 02598200 2007-08-21
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

CA 02598200 2007-08-21
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

CA 02598200 2007-08-21
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.
5
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.

CA 02598200 2007-08-21
11
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.

CA 02598200 2014-09-16
12
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.

CA 02598200 2014-09-16
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.

CA 02598200 2007-08-21
13
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.

CA 02598200 2007-08-21
-
14
E911
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.

Representative Drawing

Sorry, the representative drawing for patent document number 2598200 was not found.

Administrative Status

2024-08-01:As part of the Next Generation Patents (NGP) transition, the Canadian Patents Database (CPD) now contains a more detailed Event History, which replicates the Event Log of our new back-office solution.

Please note that "Inactive:" events refers to events no longer in use in our new back-office solution.

For a clearer understanding of the status of the application/patent presented on this page, the site Disclaimer , as well as the definitions for Patent , Event History , Maintenance Fee  and Payment History  should be consulted.

Event History

Description Date
Time Limit for Reversal Expired 2020-08-31
Inactive: COVID 19 - Deadline extended 2020-08-19
Inactive: COVID 19 - Deadline extended 2020-08-19
Inactive: COVID 19 - Deadline extended 2020-08-06
Inactive: COVID 19 - Deadline extended 2020-08-06
Common Representative Appointed 2019-10-30
Common Representative Appointed 2019-10-30
Letter Sent 2019-08-21
Change of Address or Method of Correspondence Request Received 2018-12-04
Letter Sent 2017-03-24
Inactive: Single transfer 2017-03-14
Grant by Issuance 2015-10-27
Inactive: Cover page published 2015-10-26
Pre-grant 2015-07-07
Inactive: Final fee received 2015-07-07
Notice of Allowance is Issued 2015-01-08
Letter Sent 2015-01-08
Notice of Allowance is Issued 2015-01-08
Inactive: Approved for allowance (AFA) 2014-12-10
Inactive: Q2 passed 2014-12-10
Correct Inventor Requirements Determined Compliant 2014-09-24
Inactive: Office letter 2014-09-24
Letter Sent 2014-09-24
Amendment Received - Voluntary Amendment 2014-09-16
Inactive: Single transfer 2014-09-11
Inactive: Correspondence - Formalities 2014-09-11
Correct Applicant Request Received 2014-09-11
Maintenance Request Received 2014-08-13
Inactive: S.30(2) Rules - Examiner requisition 2014-05-23
Inactive: Report - No QC 2014-05-20
Maintenance Request Received 2013-08-19
Letter Sent 2012-06-15
Request for Examination Received 2012-06-05
Request for Examination Requirements Determined Compliant 2012-06-05
All Requirements for Examination Determined Compliant 2012-06-05
Inactive: Correspondence - MF 2010-08-10
Inactive: Delete abandonment 2009-01-14
Deemed Abandoned - Failure to Respond to Notice Requiring a Translation 2008-12-23
Inactive: Compliance - Formalities: Resp. Rec'd 2008-11-04
Inactive: Declaration of entitlement - Formalities 2008-11-04
Inactive: Incomplete 2008-09-23
Application Published (Open to Public Inspection) 2008-02-21
Inactive: Cover page published 2008-02-20
Inactive: IPC assigned 2007-10-15
Inactive: First IPC assigned 2007-10-15
Inactive: IPC assigned 2007-10-15
Inactive: IPC assigned 2007-10-15
Inactive: IPC assigned 2007-10-15
Inactive: IPC assigned 2007-10-15
Inactive: Declaration of entitlement - Formalities 2007-10-11
Application Received - Regular National 2007-09-20
Inactive: Filing certificate - No RFE (English) 2007-09-20
Filing Requirements Determined Compliant 2007-09-20

Abandonment History

Abandonment Date Reason Reinstatement Date
2008-12-23

Maintenance Fee

The last payment was received on 2015-08-17

Note : If the full payment has not been received on or before the date indicated, a further fee may be required which may be one of the following

  • the reinstatement fee;
  • the late payment fee; or
  • additional fee to reverse deemed expiry.

Please refer to the CIPO Patent Fees web page to see all current fee amounts.

Owners on Record

Note: Records showing the ownership history in alphabetical order.

Current Owners on Record
INTRADO INC.
Past Owners on Record
AVI KRIVOROT
LEV DEICH
ZOHAR KRIVOROT
Past Owners that do not appear in the "Owners on Record" listing will appear in other documentation within the application.
Documents

To view selected files, please enter reCAPTCHA code :



To view images, click a link in the Document Description column. To download the documents, select one or more checkboxes in the first column and then click the "Download Selected in PDF format (Zip Archive)" or the "Download Selected as Single PDF" button.

List of published and non-published patent-specific documents on the CPD .

If you have any difficulty accessing content, you can call the Client Service Centre at 1-866-997-1936 or send them an e-mail at CIPO Client Service Centre.


Document
Description 
Date
(yyyy-mm-dd) 
Number of pages   Size of Image (KB) 
Description 2007-08-21 14 485
Abstract 2007-08-21 1 22
Claims 2007-08-21 3 67
Cover Page 2008-02-07 1 36
Drawings 2007-08-21 2 145
Description 2014-09-16 19 621
Drawings 2014-09-16 3 63
Claims 2014-09-16 4 138
Cover Page 2015-10-06 1 36
Filing Certificate (English) 2007-09-20 1 170
Reminder of maintenance fee due 2009-04-22 1 112
Reminder - Request for Examination 2012-04-24 1 118
Acknowledgement of Request for Examination 2012-06-15 1 174
Courtesy - Certificate of registration (related document(s)) 2014-09-24 1 104
Commissioner's Notice - Application Found Allowable 2015-01-08 1 162
Courtesy - Certificate of registration (related document(s)) 2017-03-24 1 127
Maintenance Fee Notice 2019-10-02 1 179
Correspondence 2007-09-20 1 20
Correspondence 2007-10-11 3 53
Correspondence 2008-09-17 1 29
Correspondence 2008-11-04 3 81
Fees 2009-06-10 1 57
Fees 2010-04-23 1 57
Correspondence 2010-08-10 1 46
Fees 2011-07-04 1 55
Correspondence 2012-04-24 1 24
Correspondence 2012-06-15 1 89
Fees 2012-06-05 1 59
Fees 2013-08-19 1 58
Fees 2014-08-13 1 54
Correspondence 2014-09-11 4 107
Correspondence 2014-09-24 1 23
Final fee 2015-07-07 2 57
Fees 2016-08-19 1 25