U.S. patent application number 12/801769 was filed with the patent office on 2010-10-28 for voice over internet protocol (volp) location based 911 conferencing.
Invention is credited to Jon Croy, John Gordon Hines, Darrin Johnson.
Application Number | 20100272242 12/801769 |
Document ID | / |
Family ID | 37985416 |
Filed Date | 2010-10-28 |
United States Patent
Application |
20100272242 |
Kind Code |
A1 |
Croy; Jon ; et al. |
October 28, 2010 |
Voice over internet protocol (VolP) location based 911
conferencing
Abstract
Voice Over Internet Protocol (VoIP) emergency calls to an
Emergency Response Center (ERC) are handled through a VoIP
conference bridge on a VoIP service provider's soft switch. The
soft switch works with a VoIP positioning center (VPC) to obtain
location information, which is compared against a PSAP database to
find an initial best-appropriate PSAP for the location of the
emergency caller. The PSAP is issued an Invite message to join the
conference, establishing an emergency call. Third parties such as
police, ambulance may be issued Invite messages to join the
conference. Cold transfers are avoided by Inviting participants to
join a single emergency conference rather than passing an emergency
call from party to party (e.g., from PSAP to police to ambulance,
etc.) The PSAP, other emergency responders, and even the initial
VoIP emergency caller may leave and rejoin the VoIP conference
without dropping the conference between the others.
Inventors: |
Croy; Jon; (Seattle, WA)
; Hines; John Gordon; (Kirkland, WA) ; Johnson;
Darrin; (Monroe, WA) |
Correspondence
Address: |
MANELLI DENISON & SELTER PLLC
2000 M Street, N.W., 7th Floor
Washington
DC
20036-3307
US
|
Family ID: |
37985416 |
Appl. No.: |
12/801769 |
Filed: |
June 24, 2010 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11503912 |
Aug 15, 2006 |
7796543 |
|
|
12801769 |
|
|
|
|
60723960 |
Oct 6, 2005 |
|
|
|
60733789 |
Nov 7, 2005 |
|
|
|
60723961 |
Oct 6, 2005 |
|
|
|
Current U.S.
Class: |
379/45 |
Current CPC
Class: |
H04M 3/42348 20130101;
H04M 11/04 20130101; H04M 7/0078 20130101; H04M 3/56 20130101; H04M
3/5116 20130101; H04M 2242/04 20130101; H04M 2242/30 20130101 |
Class at
Publication: |
379/45 |
International
Class: |
H04M 11/04 20060101
H04M011/04 |
Claims
1. A method of connecting an emergency caller with an emergency
response center, comprising: establishing an emergency call
conference; adding said emergency caller to said established
emergency call conference; and adding said emergency response
center to said emergency call conference; wherein said emergency
call is established after said emergency caller and said emergency
response center are both added to said emergency call
conference.
2-16. (canceled)
Description
[0001] This application is related to and claims priority from a
co-pending U.S. Provisional Application No. 60/723,960, entitled
"Voice Over Internet Protocol (VoIP) Location Based Conferencing",
filed on Oct. 6, 2005; U.S. Provisional Application No. 60/733,789,
entitled "Voice Over Internet Protocol (VoIP) Multi-User
Conferencing", filed on Nov. 7, 2005; and U.S. Provisional
Application No. 60/723,961, entitled "Voice Over Internet Protocol
(VoIP) Location Based 911 Conferencing", filed on Oct. 6, 2005; the
entirety of all three of which are expressly incorporated herein by
reference.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] This invention relates generally to Voice Over Internet
(VoIP) protocols and architectures. More particularly, it relates
to location based services for the provision of 911 emergency
services using VoIP protocols and architectures.
[0004] 2. Background of the Related Art
[0005] 911 is a phone number widely recognized in North America as
an emergency phone number that is used by emergency dispatch
personnel, among other things, to determine a location of a caller.
Enhanced 911 (E911) is defined by the transmission of callback
number and location information. E911 may be implemented for
landline and/or wireless devices.
[0006] A Public Safety Answering Point (PSAP) is a dispatch office
that receives 9-1-1 calls from the public. A PSAP may be a local,
fire or police department, an ambulance service or a regional
office covering all services. A 9-1-1 ("911") service becomes
E-9-1-1 ("E911") when automatic number identification and automatic
location information from a communications device (e.g. wireless
phone, VoIP Phone, etc.) is provided to the 911 operator.
[0007] Voice-Over-Internet Protocol (VoIP) is a technology that
emulates a phone call, but instead of using a circuit based system
such as the telephone network, utilizes packetized data
transmission techniques most notably implemented in the Internet.
911 calls made using VoIP technology must reach the correct PSAP,
but there currently is no uniform interface to the various PSAPs
for call delivery because the technology for connecting calls
varies. For instance, not all PSAPs are Internet Protocol (IP)
capable. Some PSAPs are accessed via ordinary public switched
telephone network (PSTN) telephone lines. Some PSAPs are accessed
through selective routing such as direct trunks. Still other PSAPs
are accessed using IP connections. There is no uniformity among the
thousands of different PSAPs.
[0008] Moreover, some Public Safety Access Points (PSAPs) are not
enhanced, and thus do not receive the callback or location
information at all from any phone, landline or wireless.
[0009] The use of VoIP technology is growing quickly. As people
adopt voice-over-IP (VoIP) technology for routine communications,
the inventors herein recognize that there is a growing need to
access E911 services including provision of location information
from a VoIP device.
[0010] The existing E911 infrastructure is built upon copper wire
line voice technology and is not fully compatible with VoIP. Given
VoIP technology, there are at least three VoIP scenarios: [0011] 1.
A VoIP UA that is physically connected to a static data cable at a
"home" address. For instance, an Analog Telephone Adapter (ATA)
that is connected to the "home" data cable and uses traditional
telephone devices. [0012] 2. A VoIP UA that is physically connected
to a data cable at a location different than its "home" address.
For instance, a laptop computer device utilized away from home as a
VoIP software telephone would be a VoIP `visitor` device as
described by this scenario. [0013] 3. A VoIP UA that is wireless,
physically disconnected from any data cable. In this situation, the
VoIP UA connects to the VoIP service provider via either a
wide-area wireless technology (e.g., cellular, PCS, WiMAX) or via a
local-area wireless technology (e.g., Wireless Fidelity (WiFi),
UWB, etc.) using a laptop computer or handheld device.
[0014] VoIP phone calls are routed to a VoIP voice gateway, from
which they are passed on to their destination. A VoIP voice gateway
or soft switch is a programmable network switch that can process
the signaling for all types of packet protocols. Also known as a
`media gateway controller,` `call agent,` or `call server, such
devices are used by carriers that support converged communications
services by integrating SS7 telephone signaling with packet
networks. Softswitches can support, e.g., IP, DSL, ATM and frame
relay.
[0015] The challenges evident with respect to determining the
location of a calling VoIP telephone is perhaps most evident with
respect to its use to make an emergency call (e.g., a 911 call).
Nevertheless, VoIP telephone technology is quickly replacing
conventional switched telephone technology. However, because VoIP
is Internet Protocol (IP) based, call related information such as
CallerID type services may not be available or accurate. A location
of a given VoIP device may be provisioned to be at a given
geographic location, or queried from a home location register (HLR)
in a mobile system.
[0016] In addition, some Public Safety Access Points (PSAPs) are
not enhanced, and thus do not receive the callback or location
information at all from any phone; landline, cellular or VoIP.
[0017] Moreover, there is complexity in public access to Public
Safety Answering Points due to lack of a Session Initiation
Protocol (SIP) Uniform Resource Identifier (URI) for all PSAPs.
(SIP is the IP-based protocol defined in IETF RFCs 3261 and 2543.)
SIP is one of two dominant protocols used by the VoIP industry. URI
is the addressing technology for identifying resources on the
Internet or a private intranet. URIs were originally defined as two
types: Uniform Resource Locators (URLs) which are addresses with
network location, and Uniform Resource Names (URNs) which are
persistent names that are address independent. Today, a URI is
defined by its purpose rather than the URL vs. URN classification.)
Some PSAPs are accessed only by conventional telephone line, others
only by direct telephone trunk lines. Not all PSAPs are accessible
via the Internet.
[0018] FIG. 5 shows basic conventional VoIP elements required to
interconnect a VoIP emergency E911 caller to a relevant public
safety access point (PSAP).
[0019] In particular, as shown in FIG. 5, VoIP telephone devices
102a, 102b, 102c (collectively referred to as 102) are connected to
respective VoIP Service Provider (VSP) soft switches 104a, 104b,
104c (collectively referred to as 104) using an Internet Protocol
(IP) connection, most commonly over the Internet. The VoIP service
provider's soft switch 104 in turn communicates with a respective
VoIP Positioning Center (VPC) 106a, 106b, 106c (collectively
referred to as 106) using an appropriate IP connection. Each VSP
requires use of their own VPC, as depicted in FIG. 5.
[0020] FIG. 6 shows in more detail conventional VoIP elements
required by a VPC to interconnect a VoIP emergency E911 caller to a
relevant public safety access point (PSAP).
[0021] In particular, as shown in FIG. 6, each VPC 106 comprises
its own respective route determination module 404, call delivery
module 406, and provisioning list 408.
[0022] A respective location information server (LIS) 108 services
each of the VPCs 106. The LIS 108 is responsible for storing and
providing access to the subscriber location information needed for
E9-1-1 call processing (as defined by the NENA VoIP Location
Working Group).
[0023] A conventional VoIP Positioning Center (VPC) 106 is a system
that attempts to determine the appropriate or correct PSAP 114 that
a VoIP emergency E911 call should be routed to based on the VoIP
subscriber's position. The conventional VPC 106 also returns
associated routing instructions to the VoIP network. The
conventional VPC 106 additionally provides the caller's location
and the callback number to the relevant PSAP through the automatic
location identifier (ALI) (The ALI is a database that accepts a
PSAP query, and using that relates a specific telephone number to a
street address. In the case of an Emergency Services Query Key
(ESQK), the ALI database steers the query to the appropriate VPC
and steers the response back to the PSAP. An ALI is typically owned
by a LEC or a PSAP.)
[0024] Further as shown in FIG. 6, each VSP route the emergency
9-1-1 call, without location object added, to their VPC 106. The
VPC must determine the correct PSAP 114 (collectively represented
by PSAP 114a, 114b and 114c) and route to it using the appropriate
technology.
[0025] In a first scenario, the VPC 106 passes the 9-1-1 call to
the PSAP 114a using an INVITE telephone number message, via a media
gateway 110 that translates between the IP protocol of the INVITE
message and a telephone line interface, and interfaces with the
public switched telephone network (PSTN) 112.
[0026] In a second scenario, the VPC 106 passes the 9-1-1 call to
the PSAP 114b using an INVITE S/R message, via an ESGW 120 and
selective router 122. In this scenario, the selective router 122 is
connected to the relevant PSAP 114b via direct trunks.
[0027] In a third scenario, the VPC 106 passes the 9-1-1 call to
the PSAP 114c using an INVITE PSAP message, via IP, to the PSAP
114c.
In the second and third scenario, the ALI 126 must be
inter-connected with each VPC 106 (a, b, c). Furthermore, each VPC
is burdened with supporting all the various ALI protocols: ve2, e2,
PAM, legacy NENA, etc.
[0028] Thus, as can be appreciated, an Emergency call (e.g., 911,
E911) may require the involvement of one or more Response Centers
(RCs), e.g., Public Safety Access Point (PSAP) in addition to the
RC that initially receives the emergency call. This is because
there is a possibility that the emergency call is received by a
PSAP other than that which is assigned to the geographic region
that the caller is currently located in.
[0029] Accordingly, the PSAP that initially answers the call may
need to transfer the emergency call to the correct PSAP. During
transfer of the emergency VoIP call, the original RC may or may not
remain on the line, but for safety purposes will not likely want to
disconnect or cold transfer the emergency call. This is because
errors may occur in the transfer, resulting in valuable time lost.
One cause of a faulty transfer of the E911 call would be that the
VoIP user has not updated the location stored by the VPC, or quite
simply that bad routing has occurred. Another cause would be that
the nature of the emergency requires multiple parties to be
involved (e.g., fire/police, police/FBI, ambulance/CDC, etc.).
[0030] Conventional solutions are based on tools that can be used
to find the phone numbers of other emergency response centers. The
ERC receiving the call initially will perform a look-up for the
correct response center, and may dial the identified correct
response center, agency, etc., and transfer the call via direct
dial/public switched telephone network (PSTN.
[0031] One exemplary conventional solution is called an Intelligent
Emergency Network (IEN), available from Intrado Inc. of Longmont,
Colo. However, such conventional solutions typically require the
emergency response center to know the direct dial lines of every
PSAP, ESP, ERC, etc. nationally. Moreover, those lines may not
always be staffed. Other potential problems would be caused if no
automatic location identification (ALI) information is accessible
or available.
[0032] There is a need for an architecture and methodology that
both simplifies the complexity of a VoIP call transfers with
respect to an emergency response center such as a public safety
access point (PSAP).
SUMMARY OF THE INVENTION
[0033] In accordance with the principles of the present invention,
a method of connecting an emergency caller with an emergency
response center comprises establishing an emergency call
conference. The emergency caller is added to the established
emergency call conference, and the emergency response center is
added to the emergency call conference. The emergency call is
established after the emergency caller and the emergency response
center are both added to the emergency call conference.
BRIEF DESCRIPTION OF THE DRAWINGS
[0034] FIG. 1 shows an exemplary architecture of a VoIP emergency
call conference bridge application operating in a VoIP soft switch
of a VoIP provider to provide VoIP emergency call conferencing, in
accordance with the principles of the present invention.
[0035] FIG. 2 shows an exemplary message flow diagram of VoIP
location based 911 conferencing, in accordance with the principles
of the present invention.
[0036] FIG. 3 shows an exemplary architecture of a VoIP conference
bridge application operating in a VoIP soft switch of a VoIP
provider to provide VoIP emergency call conferencing, in accordance
with the principles of the present invention.
[0037] FIG. 4 shows an exemplary message flow diagram for
establishing a VoIP location based conference, in accordance with
the principles of the present invention.
[0038] FIG. 5 shows basic conventional VoIP elements required to
interconnect a VoIP emergency E911 caller to a relevant public
safety access point (PSAP).
[0039] FIG. 6 shows in more detail conventional VoIP elements
required to interconnect a VoIP emergency E911 caller to a relevant
public safety access point (PSAP).
DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS
[0040] The present invention handles emergency calls through the
use of a conference bridge on a VoIP service provider's soft
switch. The soft switch works with a VoIP positioning center (VPC)
to obtain location information, which may be gathered or confirmed
by the initial recipient of the call, to ensure that appropriate
participants to the emergency conference call are Invited to join
the call. With the present invention in place, any number of
emergency calls can be made, including any number of ERCs, PSAPs,
ERPs, etc., (limited only by the number of conference bridges that
can be established in provisioned equipment, e.g., in the VoIP
service provider's soft switch). Cold transfers can be avoided by
Inviting participants to join a single emergency conference rather
than passing an original call from party to party (e.g., from PSAP
to police to ambulance, etc.) Moreover, the emergency call can
survive as long as a participant remains in the emergency
conference call, even after the original emergency caller hangs
up.
[0041] FIG. 1 shows an exemplary architecture of a VoIP emergency
call conference bridge application operating in a VoIP soft switch
of a VoIP provider to provide VoIP emergency call conferencing, in
accordance with the principles of the present invention.
[0042] In particular, as shown in FIG. 1, a user of a VoIP
communications device 104 makes an emergency call (e.g., a 911
call). The VoIP service provider of the VoIP communications device
104 receives the 911 call, and assigns it to an available VoIP
emergency conference call bridge 100. The soft switch 102 obtains
location information relating to the VoIP communications device
104, either directly from the VoIP communications device 104 itself
(e.g., if it includes a GPS device) or from a VoIP positioning
center (VPC). The VoIP soft switch 102 compares the location
information in a PSAP lookup database 800 to determine an initial
PSAP for the service area responsible for the location of the VoIP
communications device 104. The PSAP lookup database provides an
appropriate URL or other address information of the initial PSAP to
the VoIP soft switch 102, which in turn addresses an Invite message
804 (preferably including location information relating to the
location of the VoIP communications device 104). The PSAP 810, in
response, sends either an Accept message or a Reject message to the
soft switch 102 in response to the Invite message 804. Additional
emergency services departments (e.g., police 812, fire 814, etc.)
may be subsequently sent an Invite message to join the same VoIP
emergency conference call.
[0043] Thus, the VoIP communication device 104 dials the
appropriate emergency number (e.g., 911), and in response the VoIP
service provider's soft switch 102 otherwise responsible for
routing the user's calls instead establishes a VoIP conference
bridge 100 and places the incoming emergency call into the VoIP
conference bridge 100.
[0044] Although the initial emergency VoIP communication device 104
is a VoIP device, the soft switch 102 may additionally include
interfaces to the Public Switched Telephone Network (PSTN) to
permit non-VoIP emergency service provider's to join into the VoIP
conference bridge.
[0045] Alternatively, instead of automatically placing the initial
VoIP emergency caller 104 into the established VoIP conference
bridge 100, the VoIP soft switch 102 may instead Invite the initial
VoIP emergency caller 104 to join the conference call via the VoIP
conference bridge 100. In response, the initial VoIP emergency
caller 104 presumably accepts the Invite message and joins the VoIP
conference bridge 100.
[0046] At this point, the soft switch 102 may confirm location with
the initial VoIP emergency caller 104 (if location information was
provided with the initial call from the VoIP communication device
104), or determines location from the subscriber's VPC, and
captures the Location Object (LO).
[0047] The initial VoIP emergency caller 104 sends the LO and a 911
Invite message with an RC type (e.g., Fire Department, Homeland
Security, etc.) to the soft switch 102 managing the VoIP conference
bridge 100.
[0048] The soft switch 102 sends the LO and Invite information to
the VPC, which identifies the proper additional conference
participant(s) (e.g., a PSAP, RC, first responder, other interested
party, etc.) and corresponding contact information, and invites the
proper participants to join the call.
[0049] The invited participant(s) can also invite other entities to
join the VoIP emergency conference. While it is presumed that all
participants in the VoIP emergency conference call may participate
in the call, it is possible to include `listen only` participants.
For instance, a voice and/or data recording line may be invited to
the VoIP emergency conference call to record any data and/or voice
conversation.
[0050] FIG. 2 shows an exemplary message flow diagram of VoIP
location based 911 conferencing, in accordance with the principles
of the present invention.
[0051] In particular, as shown in FIG. 2, an emergency call 712
(e.g., 911) is placed from VoIP communications device 104.
[0052] In response, the VoIP soft switch establishing the VoIP
emergency conference call bridge transmits an emergency VoIP
conference call Invite message (with or without a location object)
714 (or other location request) to the VoIP Positioning Center
(VPC) 701. Based on the location of the initiating VoIP emergency
caller 104, the VPC pass at least one Invite message using Internet
Protocol (e.g., over the Internet) to interested third parties such
as an initially contacted RC-1/PSAP 702, PSAP-2 703, PSAP-n 704,
etc. The first emergency center contacted (RC-1/PSAP 702) responds
by verifying the location object and passing the same, along with
the Invite RC Type, to the soft switch 718.
[0053] As the emergency call progresses, other emergency responders
may be brought into the VoIP emergency conference call. For
instance, the soft switch that manages the VoIP conference call
bridge 100 initiates an Invite message with location object to the
VPC 701, which in turn transmits an Invite message 722 to a
subsequent emergency response center (e.g., PSAP-2 703). That
subsequent emergency response center 703 responds by
verifying/modifying the location object, and the Invite RC Type, as
shown in message 724.
[0054] The VoIP soft switch 102 may continue to invite additional
emergency responders (or other parties) by passing an Invite
message with location object through the VPC 701, which passes an
Invite with location object to the relevant other emergency
responders 704.
[0055] As an example to explain advantages of the present
invention, the scenario is given where an emergency 9-1-1 call is
routed to a PSAP based on a presumed or default location of the
VoIP caller, but in fact it turns out that the PSAP that receives
the VoIP call is not the correct entity to handle emergency calls
from the particular location that the VoIP caller is currently at.
Such errors may occur, e.g., due to the user not updating the SLDB,
bad routing, etc. In this scenario, the initial VoIP communications
device dials 9-1-1, a conference line is initiated by the soft
switch, an initially determined PSAP receives an Invite message to
join the VoIP emergency conference bridge. The PSAP
confirms/determines the user's location, and in the given scenario
would determine that another PSAP is needed instead of or in
addition to the PSAP on the line. In particular, the initial PSAP
captures the Location Object (LO) and either rejects the Invite to
join the VoIP emergency conference call (and is then removed from
the conference bridge) or continues to participate in the VoIP
emergency conference call (and so then stays on the conference
bridge). Either way, a 911 emergency call Invite message is sent
with the LO to the soft switch managing the VoIP emergency
conference bridge. The VoIP soft switch sends the LO to the VPC,
which then identifies the proper PSAP based on the LO and initiates
an Invite message addressed over IP to the proper PSAP to join into
the VoIP emergency conference call through the soft switch.
[0056] The VoIP conference bridge then joins the proper. PSAP to
the VoIP emergency conference call with the initial VoIP emergency
caller (and with the initially contacted PSAP, if the initially
contacted PSAP continues to participate in the call). In this
manner, the initial VoIP emergency caller is kept on the line
throughout the process, with preferably no additional manual action
or key entry required from the initial emergency caller.
[0057] At the conclusion of the VoIP emergency call, the VoIP
conference bridge is closed.
[0058] In cases where the initial routing of the VoIP emergency
call was correct, the VoIP conference bridge would still be used,
and the initial two parties would participate in the VoIP emergency
conference call (e.g., the initial VoIP emergency caller and the
initially Invited RC or PSAP). If no other parties are invited,
additional queries to the VoIP Positioning Center (VPC) would not
be necessary. If additional parties are invited, the soft switch
would use location information and RC Type information from the
initial RC or PSAP to determine the identity of other relevant RCs
and/or PSAPs.
[0059] In general principle, FIG. 3 shows an exemplary architecture
of a VoIP conference bridge application operating in a VoIP soft
switch of a VoIP provider to provide VoIP call conferencing, in
accordance with the principles of the present invention.
[0060] In particular, as shown in FIG. 3, a VoIP communications
device 104 is serviced by their service provider's soft switch 102.
A positioning center 106 provides location data upon request from
the soft switch 102. Other VoIP users 110, 112, 114 etc. are
potential members of any given conference.
[0061] Conference bridges 100 are implemented on the VoIP soft
switch 102 located, e.g., at the VoIP service provider's VoIP
network.
[0062] While the VoIP soft switch 102 is preferably capable of
being provisioned with as many VoIP conference bridges 100 as are
required in any particular application, only one conference bridge
100 is shown in FIG. 3 for simplicity of explanation.
[0063] Also, while the conference bridge 100 is shown implemented
in the soft switch 102, it can be embodied within another suitable
network element having an Internet Protocol (IP) type connection
(e.g., TCP/IP) with the initial user 104 as well as with the
potential conferees 110, 112, 114.
[0064] In accordance with the principles of the present invention,
location information relating to the initial VoIP user 104 is
passed to the VoIP conference bridge 100, either from the user's
VoIP communication device 104 or from their respective location
server 106. The location information is then compared by the VoIP
soft switch 102 to find an initial desired PSAP.
[0065] The VoIP soft switch 102 makes use of the location
information and other existing data or user input (e.g., existing
preferences on file on the Soft Switch 102, user entry through the
keypad of the communications device 104, or voice response). Based
on the location and user input, the VoIP conference bridge 100
identifies the desired PSAP to be asked or Invited to join the
conference currently established by the initial VoIP user 104 on
the conference bridge 100, and outputs an Invite or request message
204 to join that conference 100 to the specific URL(s), phone
number(s) and/or other identifying address information relating to
VoIP communications equipment 110, 112, 114 of the relevant
PSAP.
[0066] The soft switch 102 may also maintain the attributes and
rules from other VoIP communication devices 110, 112, 114 etc. for
receiving conference bridge calls, as well as the fixed location
(e.g., a place of business) or the ability to query for a current
location (e.g., for mobile communication devices such as mobile
phones) for each device. Based on this information, with or without
other user input (e.g., to select or prioritize among a list of
available third parties), the soft switch 102 invites one or more
other communication devices 110, 112, 114, etc. to join the
conference bridge. This creates a voice link between the first user
104 and the other third parties 110, 112, 114 without requiring the
first user 104 to know the contact information or name of the third
parties 110, 112, 114.
[0067] FIG. 4 shows an exemplary message flow diagram for
establishing a VoIP location based conference, in accordance with
the principles of the present invention.
[0068] In particular, as shown in FIG. 4, the initial VoIP user 104
sends a request for conference bridge call to the soft switch 102.
Preferably the initial VoIP user 104 includes location information
with the conference request call 201. However, as depicted in FIG.
3, location information can be obtained from an appropriate
positioning server 106 if not available from the initial VoIP user
104.
[0069] Subsequent to the incoming conference call 201, a suitable
PSAP (and/or other emergency services, including a recorder line)
is determined and invited with respective invite messages 204,
206.
[0070] In operation, the user's VoIP communication device 104 dials
a pre-determined phone number (or URL) of the emergency service
(e.g., 911) to initiate a VoIP emergency conference bridge 100 on
the relevant VoIP soft switch 102.
[0071] FIG. 3 shows use of a VoIP positioning center (VPC) 106. The
VoIP soft switch 102 may receive the user's location information
either from each of the VoIP communication devices 104, 110, 112,
114 etc., or from the VPC 106.
[0072] The VoIP soft switch 102 preferably uses both the location
information of the initiating VoIP user 104, together with any
profile criteria set for a given conference bridge 100, to
determine a suitable PSAP or other emergency services entity to be
sent INVITE messages inviting them to join the established VoIP
emergency conference bridge 100.
[0073] The VoIP soft switch 102 invites one or more other VoIP
communication devices 110, 112, 114, (relating to emergency
services) to join the VoIP emergency conference bridge 100. This
creates a voice link between the initiating VoIP user 104 that
initially called into the VoIP emergency conference bridge 100, and
the other potential, third party conferees 110, 112, 114, etc.,
without requiring the initiating VoIP user 104 to know the name or
even the contact information of the other potential, third party
emergency conferees 110, 112, 114, etc.
[0074] Upon receipt of an invite to a VoIP conference bridge 204,
206, the potential other VoIP users 110, 112, 114, etc. (PSAPs) are
preferably notified similar to an incoming telephone call, e.g.
with a ring signal, though it may be customized to be distinguished
from the sound of an otherwise ordinary incoming phone call. For
instance, a given unique phone tone may be activated upon receipt
of an invite 204, 206 to a conference bridge 100.
[0075] In accordance with the principles of the present invention,
the VoIP communication device(s) 110, 112, 114 receiving
invitations to join a VoIP emergency call conference 100 may be
provided with a filter that automatically rejects any/all invite
requests not meeting their own specific criteria (e.g., the first
invited participant to accept the Invite message) maintained on
their VoIP devices 110, 112, 114 themselves, though such filtering
may alternatively be performed at a network level, e.g., at the
VoIP soft switch 102 or other centralized location.
[0076] Benefits of the invention include that there is no effective
limit to the number of participants in the VoIP emergency
conference call, there are no cold transfers of a call as VoIP
invitees enter or leave the conference bridge 100, and there is the
ability to continue the conference call even after the initial VoIP
user 104 making the emergency call disconnects.
[0077] The present invention has particular applicability with
any/all VoIP users, VoIP service providers, and Public Safety
Access Points (PSAPs).
[0078] The invited VoIP users 110, 112, 114 may include a filter
allowing through only acceptable Invite messages based on criteria
established by or on the receiving VoIP communication devices 110,
112, 114.
[0079] The present invention allows VoIP users to efficiently and
quickly find and invite their most appropriate responder to their
emergency, with minimal user interaction. This is particularly
helpful for mobile VoIP users (e.g., while driving, walking, etc.)
Moreover, there is no effective limit to the number of participants
in the conference call (within network hardware limits of the
conference bridge itself). There is also no risk of cold transfers
of a VoIP telephone call as participants aren't handled in
point-to-point connections that are transferred but rather join or
exit an established conference at will. Furthermore, emergency
personnel from various departments and locations in the conference
call can continue in the conference even after the initial
emergency caller disconnects.
[0080] Potential markets for the present invention include VoIP
service providers who may implement the inventive VoIP emergency
conference calling as a value added services for users. VoIP
location based conferencing in accordance with the principles of
the present invention has particular applicability with any/all
VoIP users, VoIP service providers, and Public Safety Access Points
(PSAPs).
[0081] While the invention has been described with reference to the
exemplary embodiments thereof, those skilled in the art will be
able to make various modifications to the described embodiments of
the invention without departing from the true spirit and scope of
the invention.
* * * * *