U.S. patent application number 14/268044 was filed with the patent office on 2014-08-28 for emergency services for packet networks.
This patent application is currently assigned to Rockstar Consortium US LP. The applicant listed for this patent is Rockstar Consortium US LP. Invention is credited to Cristian Constantinof.
Application Number | 20140241342 14/268044 |
Document ID | / |
Family ID | 43617347 |
Filed Date | 2014-08-28 |
United States Patent
Application |
20140241342 |
Kind Code |
A1 |
Constantinof; Cristian |
August 28, 2014 |
EMERGENCY SERVICES FOR PACKET NETWORKS
Abstract
The present invention provides a technique for facilitating
emergency services via packet networks. Emergency service providers
will implement emergency proxies to ensure that proper call setup
requests for emergency services are forwarded to the appropriate
entities, even if those entities are in overload conditions. The
emergency proxies may authenticate and filter call setup requests
to ensure that only proper call setup requests are forwarded to
help prevent such overload conditions. The emergency proxies may
operate solely in a packet network, as well as at the interface
between a packet network and a circuit-switched network to assist
in call setup requests originating from either the packet network
or the circuit-switched network.
Inventors: |
Constantinof; Cristian;
(Kanata, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Rockstar Consortium US LP |
Plano |
TX |
US |
|
|
Assignee: |
Rockstar Consortium US LP
Plano
TX
|
Family ID: |
43617347 |
Appl. No.: |
14/268044 |
Filed: |
May 2, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13021134 |
Feb 4, 2011 |
8737594 |
|
|
14268044 |
|
|
|
|
10606687 |
Jun 26, 2003 |
7899174 |
|
|
13021134 |
|
|
|
|
Current U.S.
Class: |
370/352 |
Current CPC
Class: |
H04L 65/105 20130101;
H04M 3/436 20130101; H04L 65/1079 20130101; H04L 65/1069 20130101;
H04M 3/5116 20130101; H04M 2242/06 20130101 |
Class at
Publication: |
370/352 |
International
Class: |
H04L 29/06 20060101
H04L029/06 |
Claims
1. A method of controlling access to an emergency service,
comprising: receiving a communication session initiation request
from an originator, the communication session initiation request
requesting initiation of a communication session with a terminating
element associated with the emergency service; determining whether
the originator is authorized to initiate the communication session;
when the originator is determined to be authorized to initiate the
communication session: providing an indication that the originator
is authorized to initiate the communication session in the
communication session initiation request; and forwarding the
communication session initiation request including the indication
toward the terminating element associated with the emergency
service; at least one of the receiving of the communication session
initiation request and the forwarding of the communication session
initiation request being via a packet network.
2. The method of claim 1, comprising, when the originator is
determined not to be authorized to initiate the communication
session, not forwarding the communication session initiation
request toward the terminating element associated with the
emergency service.
3. The method of claim 1, comprising, when the originator is
determined to be authorized to initiate the communication session,
creating emergency information for the communication session
initiation request, wherein providing an indication that the
originator is authorized to initiate the communication session in
the communication session initiation request comprises adding the
emergency information to the communication session initiation
request.
4. The method of claim 1, wherein the providing an indication that
the originator is authorized to initiate the communication session
in the communication session initiation request comprises carrying
the indication in a header of the communication session initiation
request.
5. The method of claim 1, wherein the providing an indication that
the originator is authorized to initiate the communication session
in the communication session initiation request comprises carrying
the indication in at least one parameter of the communication
session initiation request.
6. The method of claim 1, comprising determining whether the
originator is authorized to initiate the communication session only
when at least one network resource required to forward the
communication session initiation request toward the terminating
element or the terminating element is in an overload condition.
7. The method of claim 5, when the originator is determined not to
be authorized to initiate the communication session, not forwarding
the communication session initiation request toward the terminating
element associated with the emergency service.
8. The method of claim 7, comprising providing a response to the
originator when not forwarding the communication session initiation
request toward the terminating element associated with the
emergency service, the response indicating that the communication
session initiation request has not been forwarded.
9. The method of claim 1, comprising registering originators
authorized to initiate communication sessions with the emergency
service in response to received registration messages.
10. The method of claim 9, wherein determining whether the
originator is authorized to initiate the communication session
comprises determining whether the originator is registered.
11. The method of claim 1, comprising: selecting a priority level
of a plurality of priority levels for association with the
communication session initiation request; and providing an
indication of the selected priority level in the communication
session initiation request.
12. The method of claim 1, wherein the originator is a user of an
originating device.
13. The method of claim 1, wherein the originator is an originating
device.
14. The method of claim 1, wherein received communication session
initiation request is a Session Initiation Protocol (SIP) invite
message.
15. The method of claim 14, wherein the SIP invite message is
received via a packet network.
16. The method of claim 1, wherein the forwarded communication
session initiation request is a Session Initiation Protocol (SIP)
invite message, and the SIP invite message is forwarded via packet
network.
17. The method of claim 16, wherein the Indication comprises
information in a header of the forwarded communication session
initiation request, the information indicating that the forwarded
communication session initiation request is associated with an
emergency communication session.
18. The method of claim 16, wherein the Indication comprises
information in at least one parameter of the forwarded
communication session initiation request, the information
indicating that the forwarded communication session initiation
request is associated with an emergency communication session.
19. The method of claim 1, wherein received communication session
initiation request is an Initial Address Message (IAM) requesting
setup of a circuit switched communication session.
20. The method of claim 19, wherein the IAM is received via circuit
switched communication network.
21. The method of claim 1, wherein the forwarded communication
session initiation request is an Initial Address Message (IAM)
forwarded via a circuit switched communication network.
22. The method of claim 21, wherein the Indication comprises
emergency parameters in the IAM message.
23. The method of claim 1, comprising encrypting the indication in
the communication session initiation request before forwarding the
communication session initiation request toward the terminating
element.
24. The method of claim 1, wherein the communication session
initiation request is a request for a communication session of a
type selected from the group consisting of data, audio, voice and
video.
25. The method of claim 1, performed at an emergency proxy
connected to the packet network.
26. The method of claim 25, wherein the emergency proxy is
implemented at a gateway between a packet network and a
circuit-switched communication network.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] The present application is a continuation of U.S. patent
application Ser. No. 13/021,134, filed on Feb. 4, 2011, which was a
continuation of U.S. Pat. No. 7,899,174, which issued on Mar. 1,
2011, the disclosures of which are hereby incorporated by reference
in their entirety.
FIELD OF THE INVENTION
[0002] The present invention relates to communications, and in
particular to ensuring emergency calls supported in part over a
packet network are properly handled, even during overload
conditions.
BACKGROUND OF THE INVENTION
[0003] Providing emergency services, especially in overload
conditions, is challenging since service providers have to ensure
that emergency calls are established regardless of other
non-emergency calls. In the public switched telephone network
(PSTN), there are mechanisms to identify calls made from and to
special locations which involve providing emergency services. These
locations include 911 call centers, police departments, hospitals,
fire stations, and various government agencies. Generally,
excessive network resources are reserved to ensure completion of
emergency calls, and call setup requests for requesting the
establishment of a call are given processing priority when they are
within the various switching nodes within the PSTN. Accordingly,
the PSTN currently has the ability to properly prioritize and
handle emergency calls.
[0004] With respect to packet-based communications, packet networks
are increasingly being used to deploy voice-based communications
using various types of voice over packet (VoP) calls.
Unfortunately, the openness of packet-based architectures has
presented a challenge for properly handling emergency calls.
Although there are numerous packet-based devices which can filter
and route calls, this is no overriding solution for ensuring
emergency calls are properly processed and prioritized over
non-emergency calls. Further, there is a need to ensure that
emergency calls can be properly handled in overload conditions as
well as ensure that the system is not abused by malicious users who
improperly identify their calls as emergency calls or initiate
malicious attacks, such as denial of service attacks.
SUMMARY OF THE INVENTION
[0005] The present invention provides a technique for facilitating
emergency services via packet networks. Emergency service providers
will implement emergency proxies to ensure that proper call setup
requests for emergency services are forwarded to the appropriate
entities, even if the network or those entities are in overload
conditions. The emergency proxies may authenticate and filter call
setup requests to ensure that only proper call setup requests are
forwarded to help prevent abusive, malicious or unauthorized use of
emergency services. The emergency proxy may operate solely in a
packet network, as well as at the interface between a packet
network and a circuit-switched network to assist in call setup
requests originating from either the packet network or the
circuit-switched network.
[0006] Those skilled in the art will appreciate the scope of the
present invention and realize additional aspects thereof after
reading the following detailed description of the preferred
embodiments in association with the accompanying drawing
figures.
BRIEF DESCRIPTION OF THE DRAWING FIGURES
[0007] The accompanying drawing figures incorporated in and forming
a part of this specification illustrate several aspects of the
invention, and together with the description serve to explain the
principles of the invention.
[0008] FIG. 1 is a block representation of a communication
environment according to one embodiment of the present
invention.
[0009] FIG. 2 is a communication flow diagram providing an
exemplary scenario for implementing emergency services according to
one embodiment of the present invention.
[0010] FIG. 3 is a block representation of a communication
environment according a second embodiment of the present
invention.
[0011] FIG. 4 is a communication flow diagram providing an
exemplary scenario for implementing emergency services according to
a second embodiment of the present invention.
[0012] FIG. 5 is a communication flow diagram providing an
exemplary scenario for implementing emergency services according to
a third embodiment of the present invention.
[0013] FIG. 6 is a block representation of an emergency proxy
according to one embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0014] The embodiments set forth below represent the necessary
information to enable those skilled in the art to practice the
invention and illustrate the best mode of practicing the invention.
Upon reading the following description in light of the accompanying
drawing figures, those skilled in the art will understand the
concepts of the invention and will recognize applications of these
concepts not particularly addressed herein. It should be understood
that these concepts and applications fall within the scope of the
disclosure and the accompanying claims.
[0015] With reference to FIG. 1, a communication environment 10 is
provided wherein an originating element 12 is a communication
device attempting to establish a call to a terminating element 14
via a packet network 16. For the present invention, the term "call"
includes traditional voice-based calls, as well as media sessions,
which include any type of data, audio, voice, or video based packet
sessions. In the illustrated embodiment, the originating element 12
is supported by an emergency proxy 18, and the terminating element
14 may be supported by a proxy 20 in traditional fashion, wherein
the emergency proxy 18 and the proxy 20 will act as liaisons for
call or session establishment messages involving the respective
devices.
[0016] Accordingly, the originating element 12 will send a call
setup request configured to initiate a call between the originating
element 12 and the terminating element 14. In traditional proxy
fashion, the call setup request is received by the emergency proxy
18, which will determine if the call setup request meets the
emergency criteria of an emergency call setup request. The
emergency criteria are preferably provisioned by emergency services
providers, such that these providers can effectively control how
call setup requests are processed. If the emergency criteria are
met, the emergency proxy 18 will modify the call setup request in a
defined manner and forward the call setup request across the packet
network 16 to initiate the call. The call setup request may be
forwarded to the terminating element 14 directly or indirectly via
the proxy 20. In one embodiment, the proxy 20 may be configured to
analyze the call setup request to ensure that the call setup
request is properly configured by the emergency proxy 18 as a
condition to sending the call setup request to the terminating
element 14. As such, the emergency proxy 18 and perhaps the proxy
20 are configured to process call setup requests from the
originating element 12 to ensure that only authorized call setup
requests result in emergency calls, by effectively filtering call
setup requests actually delivered to the terminating element 14 or
supporting entities.
[0017] Preferably, the emergency proxy 18 will authenticate the
call setup request to ensure that the originating element 12 can
initiate a request for an emergency call, as well as limit the call
setup requests sent toward the terminating element 14 to those that
are authenticated. The emergency proxy 18 may add an additional
field, referred to in general as an emergency header field, to the
call setup request. The emergency header field may include
additional information that uniquely identifies the level of
emergency, and information identifying the call, such as caller
identification, to and from addresses, and the like. For additional
security to avoid malicious or unauthorized use of emergency
services, the emergency proxy 18 may encrypt the emergency header
field information in a manner allowing the proxy 20, terminating
element 14, or other supporting entity to be able to decrypt
information when attempting to establish an emergency call.
Notably, private or public key encryption techniques may be
employed that are well known in the art. Authentication of call
setup requests or an originating element 12 sending the call setup
request may be based on the identity of the originating element 12,
a user of the originating element 12, or authentication information
provided when generating the call setup request. The emergency
proxy 18 will be provisioned with the necessary information to
facilitate authentication of the various originating elements 12
that are served by the emergency proxy 18.
[0018] Notably, the emergency proxy 18 may provide multiple levels
of prioritization for various types of call setup requests and may
filter call setup requests according to these priority levels and
network conditions, as well as include indicia indicating an
assigned prioritization level in each call setup request. The
receiving proxy 20, terminating element 14, any other intermediate
proxy or supporting entity, if any, will process the incoming call
setup request according to the assigned prioritization level,
network conditions, and the like.
[0019] In a preferred embodiment, at least a portion of the
communication sessions established between the originating element
12 and the terminating element 14 are facilitated using the Session
Initiation Protocol (SIP). The specification for SIP is provided in
the Internet Engineering Task Force's Request for Comments (RFC)
3261: Session Initiation Protocol Internet Draft, which is
incorporated herein by reference in its entirety. In general, SIP
is used to establish media sessions between any number of
endpoints, such as the originating and terminating elements 12, 14.
Typically, these endpoints may support any number or combination of
data, audio, and voice media sessions, depending on the
configuration of the device. A SIP endpoint is capable of running
an application, typically referred to as a user agent (UA), which
is capable of facilitating media sessions using SIP.
[0020] In certain embodiments, user agents may register their
ability to establish sessions with a SIP proxy, such as the
emergency proxy 18 or proxy 20, by sending REGISTER messages to the
SIP proxy. The REGISTER message informs the SIP proxy of the SIP
universal resource locator (URL) that identifies the user agent to
the SIP network. The REGISTER message also contains information
about how to reach specific user agents over the SIP network,
typically by providing the Internet Protocol (IP) address and port
that the user agent will use for SIP sessions. When a user agent
wants to establish a session with another user agent, the user
agent initiating the session may send an INVITE message to the SIP
proxy and specify the target user agent in the TO header of the
INVITE message. Identification of the user agent takes the form of
a SIP URL. The SIP proxy will use the SIP URL in the TO header of
the message to determine if the targeted user agent is registered
with the SIP proxy. Generally the user name is unique within the
name space of the specified domain.
[0021] If the targeted user agent has registered with the SIP
proxy, the SIP proxy will forward the INVITE message directly to
the targeted user agent.
[0022] The targeted user agent will respond with a 200 OK message,
and a session between the respective user agents will be
established as per the message exchange required in the SIP
specification. Media capabilities are passed between the two user
agents of the respective endpoints as parameters embedded within
the session setup messages, such as the INVITE, 200 OK, and
acknowledgement (ACK) messages. Media capabilities may be exchanged
in other messages, such as the SIP INFO message. Media capabilities
are typically described using the Session Description Protocol
(SDP). Once respective endpoints are in an active session with each
other and have determined each other's capabilities, the specified
media content may be exchanged during an appropriate media
session.
[0023] According to the Internet Engineering Task Force's RFC 3261,
a user agent is an application that contains both a user agent
client and a user agent server. A user agent client generally
refers to a client application that initiates SIP requests, wherein
a user agent server is an application that contacts the user when a
SIP request is received, and returns a response on behalf of the
user. Typically, the response accepts, rejects, or redirects the
received request.
[0024] With reference to FIG. 2, a communication flow diagram is
provided from an exemplary scenario wherein one or more originating
elements 12 are sending call setup requests in the form of INVITE
messages to initiate a call via a SIP session with one or more
terminating elements 14. Assume that the terminating elements 14
provide emergency services and only emergency calls should be
handled by the terminating elements 14. Accordingly, the emergency
proxy 18 will only forward incoming call setup requests, in the
form of SIP INVITE messages, which meet the necessary criteria for
being emergency call setup requests to the terminating elements 14.
Initially, assume that an INVITE message intended to establish a
call with a terminating element 14 is sent from the originating
element 12 (step 100). Further assume that the originating element
12 is either unauthorized to establish an emergency call or that
the INVITE message would not meet the necessary criteria for
establishing an emergency call. As such, the emergency proxy 18
will determine if the INVITE message meets the defined emergency
criteria (step 102), and since this INVITE message would not meet
the emergency criteria, the emergency proxy 18 will ignore the
INVITE message and not forward the INVITE message toward the
terminating element 14 (step 104). The emergency proxy 18 may be
configured to provide a response indicative of not forwarding the
INVITE message back to the originating element 12 (not shown)
[0025] Next, assume that an appropriate originating element 12
sends a proper INVITE message for initiating an emergency call to
the terminating element 14. The emergency proxy 18 will receive the
INVITE message (step 106), and determine if the INVITE message
meets the emergency criteria (step 108). Since the INVITE message
meets the emergency criteria, the emergency proxy 18 generates an
emergency header field (step 110) and adds the emergency header
field to the INVITE message (step 112). The INVITE message is then
forwarded toward the terminating element 14 (step 114). Since the
terminating element 14 is associated with a proxy 20, the proxy 20
will receive the INVITE message on behalf of the terminating
element 14 and may be configured to determine if the proper
emergency header field is present (step 116). If the proper
emergency header field is present, the INVITE message is forwarded
to the terminating element 14 wherein the session supporting the
call can be established with the originating element 12 (step
118).
[0026] In the event that the proxy 20 receives an INVITE message
without the proper emergency header field from any device (step
120), the proxy 20 will determine if the proper emergency header
field is present (step 122), and since the field is not present,
may ignore the INVITE message (step 124). As such, the emergency
proxy 18 provides the proper authentication and filtering for call
setup requests to ensure that terminating elements 14 providing
emergency services are only sent appropriate call setup requests.
Further, the proxy 20 supporting the terminating elements 14 may
provide further authentication and filtering to ensure that the
terminating element 14 only receives appropriate call setup
requests. Again, further security may be provided using encryption
and decryption techniques between the emergency proxy 18 and the
proxy 20. The proxy 20 and the emergency proxy 18 may also monitor
work conditions to help provide filtering for the various call
setup requests, as well as prioritize the call setup requests based
on any available criteria.
[0027] Turning now to FIG. 3, the concepts of the present invention
readily extend to circuit-switched networks 22, such as the PSTN,
wherein an emergency proxy 18 is implemented in or in association
with a gateway facilitating an interface between the packet network
16 and the circuit-switched network 22. In such a configuration,
the emergency proxy 18 can control circuit-switched call setup
requests as well as packet-based call setup requests originating
from the circuit-switched network 22 and the packet network 16,
respectively.
[0028] An exemplary communication call flow for filtering call
setup requests originating from the packet network 16 and intended
for a device on the circuit-switched network 22 is provided in FIG.
4. In this example, an initial INVITE message, which does not meet
the emergency criteria, is sent from the originating element 12 to
establish an emergency call with a device in the circuit-switched
network 22. The emergency proxy 18 will receive the INVITE message
(step 200) and determine if the INVITE message meets the emergency
criteria (step 202). Since the emergency criteria are not met, the
emergency proxy 18 will ignore the INVITE message (step 204) and
perhaps report the same back to the originating element 12 (not
shown).
[0029] When an appropriate INVITE message is sent from an
originating element 12 (step 206), the emergency proxy 18 will
receive the INVITE message and determine if the INVITE message
meets the emergency criteria (step 208). Since the emergency
criteria is met, the emergency proxy 18 may generate one or more
emergency parameters (step 210) and create a call setup request
with the emergency parameter (step 212), wherein the call setup
request is configured to initiate a call in the circuit-switched
network 22. An exemplary call setup request for the PSTN is an
intelligent network Initial Address Message (IAM). As such, the
emergency proxy 18 will send a call setup request to the
appropriate entity in the circuit-switched network 22 to initiate
the emergency call (step 214). The call setup request will include
the emergency parameters to assist the entities in the
circuit-switched network 22 in determining whether the call setup
request is appropriate. The emergency parameters may be carried in
signaling information elements as specified by the appropriate
standards that define the Multi-Level Precedence and Preemption
Supplementary Service, which is well known and provides for
prioritizing voice traffic.
[0030] Turning now to FIG. 5, assume that entities in the
circuit-switched network 22 are attempting to establish emergency
calls with a terminating element 14 in the packet network 16.
Accordingly, call setup requests in the form of IAMs are received
by the emergency proxy 18 from the circuit-switched network 22
(step 300). Assume that the first call setup request would not meet
the emergency criteria for establishing an emergency call with the
terminating element 14, and as such, the emergency proxy 18 will
determine that the call setup request does not meet the emergency
criteria (step 302) and will ignore the call setup request (step
304). Again, the call setup request may be an IAM, which may
include various parameters to assist in determining whether the
emergency criteria are met.
[0031] Assume that another call setup request, which would meet the
emergency criteria, is received by the emergency proxy 18 from the
circuit-switched network 22 (step 306). The emergency proxy 18 will
determine if the call setup request meets the emergency criteria
(step 308) and since it does meet the emergency criteria, the
emergency proxy 18 will generate an emergency header field (step
310) and create an INVITE message intended for the terminating
element 14 with the emergency header field (step 312). The
emergency proxy 18 will then send the INVITE message with the
emergency header field toward the terminating element 14. The proxy
20 will receive the INVITE message (step 314) and may be configured
to determine if a proper emergency header field is present (step
316). If the proper emergency header field is present, the INVITE
message is forwarded to the terminating element 14 to establish the
emergency call (step 318). Notably, the session between the
emergency proxy 18 or associated gateway and the terminating
element 14 may be a SIP session, wherein the connection within the
circuit-switched network 22 will be a circuit-switched connection.
As described above, the proxy 20 may receive INVITE messages
without the proper emergency header field (step 320), and then
determine if the proper emergency header is present (step 322).
When the proper emergency header field is not present, the INVITE
message may be ignored (step 324).
[0032] With any of the above embodiments, the emergency proxy 18
will preferably be configured to ensure that a proper call setup
request is always forwarded to or towards the terminating element
14, even in overload conditions. Further, in non-overload
conditions, the emergency proxy 18 as well as the proxy 20 may be
configured to forward all of select INVITE messages or forward them
based on desired criteria, yet prioritize emergency requests as
well as eliminate non-emergency requests during overload
conditions.
[0033] With reference to FIG. 6, a high level block diagram of an
emergency proxy or device capable of performing the function of an
emergency proxy is illustrated. The emergency proxy 18 will
typically include a control system 24 having memory 26 for storing
the necessary software 28 to facilitate the above functionality.
The control system 24 will also be associated with one or more
communication interfaces 30 for communicating over the packet
network 16, and perhaps the circuit-switched network 22, as
necessary.
[0034] Those skilled in the art will recognize improvements and
modifications to the preferred embodiments of the present
invention. All such improvements and modifications are considered
within the scope of the concepts disclosed herein and the claims
that follow.
* * * * *