Note: Descriptions are shown in the official language in which they were submitted.
CA 02710199 2010-06-18
1 TITLE: A METHOD AND SYSTEM FOR ESTABLISHING A
2 CONNECTION WITH A PACKET-BASED APPLICATION
3 SERVER
4
FIELD OF THE INVENTION
6
7 The present invention relates generally to the field of packet-based
application
8 servers, and specifically to a method and system for enabling PSTN and
wireless
9 communication devices to establish a communication link with a packet-
based
application server.
11
12 BACKGROUND
13
14 Soft switches and other software-based call-routing switches are known
in the VoIP
world for processing VoIP calls. Many users enjoy using VoIP technology, since
the
16 software-based switches that are used to process VoIP calls are able to
provide more
17 flexibility and functionality to the processing of calls than more
traditional hardware-
18 based switches.
19
Thus, there is a need in the industry to provide a technological solution that
allows the
21 functionality and flexibility of software-based switches to be better
utilized by
22 traditional communication devices, such as wireless and PSTN communication
23 devices.
24
SUMMARY OF THE INVENTION
26
27 In accordance with a first broad aspect, the present invention provides
a method that
28 comprises receiving at a network entity managed by a network service
provider a
29 signal from a communication device indicative of an intention to
initiate a telephony
action; upon receipt of the signal indicative of an intention to initiate a
telephony
31 action, causing a communication link between the communication device
and a
32 packet-based application server to be established such that the packet-
based
33 application server can receive from the communication device information
related to
34 an intended telephony action, for example communication destination
information.
1
CA 02710199 2010-06-18
1 In accordance with a second broad aspect, the present invention provides
a network
2 entity managed by a network service provider, comprising: a first
component suitable
3 for receiving over a network connection a signal from a communication device
4 indicative of an intention to initiate a telephony action; a second
component for
causing a communication link between the communication device and a packet-
based
6 application server to be established such that the packet-based
application server can
7 receive from the communication device information related to an intended
telephony
8 action.
9
In accordance with a third broad aspect, the present invention provides a
method that
11 comprises detecting an intention to initiate a telephony action from a
communication
12 device; in response to the intention to initiate a telephony action,
issuing a request for
13 a destination of a packet-based application server that is suitable for
processing an
14 intended call from the communication device; and upon receipt of the
destination of a
packet-based application server in response to said request, causing a
communication
16 link with the packet-based application server to be established such
that the packet-
17 based application server can receive from the communication device
information
18 related to an intended telephony action.
19
In accordance with a fourth broad aspect, the present invention provides a
system that
21 comprises a packet based application server suitable for routing an
intended telephony
22 action and; a network entity managed by a network service provider. The
network
23 entity comprising: a first component suitable for receiving over a
network connection
24 a signal from a communication device indicative of an intention to
initiate a telephony
action; a second component for causing a communication link between the
26 communication device and said packet-based application server to be
established,
27 such that the packet-based application server can receive from the
communication
28 device information related to an intended telephony action.
29
In accordance with a fifth broad aspect, the present invention provides a
31 communication device suitable for initiating a telephony action, said
communication
32 device comprising: a processing unit suitable for generating a request
for a destination
33 of a packet-based application server that is suitable for processing an
intended call
2
CA 02710199 2010-06-18
1 from said communication device and an interface suitable for: issuing
said request
2 over a network connection; in response to receipt of a destination of a
packet-based
3 application server in response to said request, causing a communication
link with a
4 packet-based application server to be established such that the packet-
based
application server can receive from said communication device information
related to
6 an intended telephony action.
7
8 In accordance with a sixth broad aspect, the present invention provides a
computer-
9 readable storage medium comprising a program element for execution by a
processing
unit to implement a network entity, said program element comprising: first
program
11 code for receiving at the network entity managed by a network service
provider a
12 signal from a communication device indicative of an intention to
initiate a telephony
13 action; second program code for causing a communication link between the
14 communication device and a packet-based application server to be
established, upon
receipt of the signal indicative of an intention to initiate a telephony
action, such that
16 the packet-based application server can receive from the communication
device
17 information related to an intended telephony action.
18
19 These and other aspects and features of the present invention will now
become
apparent to those of ordinary skill in the art upon review of the following
description
21 of specific embodiments of the invention in conjunction with the
accompanying
22 drawings.
23
24 BRIEF DESCRIPTION OF THE DRAWINGS
26 In the accompanying drawings:
27
28 Fig 1 shows a communication network comprising a packet-based
application server
29 for processing telephony actions made from different communication devices
in
accordance with a non-limiting embodiment of the present invention;
31
2a
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 Fig 2 shows a method for establishing a communication link between a
packet-based
2 application server and a communication device in accordance with a first
non-limiting
3 embodiment of the present invention;
4
Fig 3 shows a functional block diagram of a network entity in accordance with
a non-
6 limiting embodiment of the present invention;
7
8 Figure 4 shows an expanded flow chart of a method for establishing a
communication
9 link between a communication device and a packet-based application
server, in
accordance with a non-limiting embodiment of the present invention;
11
12 Figure 5 shows three non-limiting representations of the manner in which
a
13 communication link can be established between a communication device and
a
14 packet-based application server in accordance with a non-limiting
embodiment of the
present invention; and
16
17 Figure 6 shows a method for establishing a communication link between a
packet-
18 based application server and a communication device in accordance with a
second
19 non-limiting embodiment of the present invention.
21 It is to be expressly understood that the description and drawings are
only for the
22 purpose of illustration of certain embodiments of the invention and are
an aid for
23 understanding. They are not intended to be a definition of the limits of
the invention.
3
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1
2 DETAILED DESCRIPTION OF NON-LIMITING EMBODIMENTS
3
4 Shown in Figure 1 is a non-limiting example of a communication
architecture 10 that
is suitable for enabling communication between different communication
devices.
6 The communication architecture 10 includes network portions 18, 20 and 22
that
7 enable the handling of incoming communications, outgoing communications
and
8 communications in progress for communication devices 12, 14 and 16. The
9 communication architecture 10 also includes a packet-based application
server 30,
such that in accordance with the present invention, communications originating
from
11 the communication devices 12, 14 and 16 can be routed to a called party
or another
12 appropriate destination either by equipment in one or more of the
network portions
13 18, 20 and 22, or in certain circumstances, by the packet-based
application server 30.
14 Routing and processing calls via the packet-based application server 30
allows
increased flexibility and functionality to be applied to the handling of
communications
16 originating from, destined for or ongoing at the communication devices
12, 14 and 16,
17 as well as certain other telephony actions, such as checking voice mail.
18
19 The network portions 18, 20 and 22 shown in Figure 1 may comprise a
portion of one
or more of a Public Switched Telephone Network (PSTN), a wireless network
(e.g., a
21 cellular network), and a data network (e.g., the Internet). In the
example shown,
22 network portion 18 comprises a portion of a Public Switched Telephone
Network
23 (PSTN) and is responsible for handling communications originating from,
and
24 destined for, POTS (Plain Old Telephony System) communication devices,
such as
POTS communication device 12. The network portion 18 can include a PSTN line,
26 and PSTN equipment for switching and routing calls. For example, network
entity 24
27 can be a DMS switch, among other possibilities.
28
29 Network portion 20 comprises a portion of a wireless network (e.g., a
cellular
network) that is responsible for handling communications originating from, and
31 destined for, wireless communication devices, such as the wireless
communication
32 device 14. The wireless communication device 14 can be a cellular phone,
a smart-
33 phone or any other mobile communication device, including atelephony-
enabled
34 personal digital assistant (PDA), known in the art. The network portion
20 may
4
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 include a
wireless link in combination with a base station and a network-side wireline
2 link, as
well as wireless equipment suitable for routing wireless communications, such
3 as network
entity 26. The network entity 26 can be a mobile switching center, among
4 other possibilities.
6 Finally,
network portion 22 is a data network, such as the Internet or a digital
7
communications link (e.g., a digital subscriber line (DSL) link or a coaxial
cable) that
8 is
responsible for handling communications originating from, and destined for,
VoIP
9 communication devices, such as VoIP communication device 16. The VoIP
communication device 16 can be a dedicated VoIP phone, a POTS phone equipped
11 with an
analog terminal adapter (ATA) or a soft phone (i.e., a computer equipped with
12 telephony
software), among other possibilities. In certain circumstances, network
13 portion 22
may not require a network entity having switching/routing functionality,
14 since in
the case of VoIP communication devices, the switching/routing functionality
may be performed directly by the packet-based application server 30. However,
in
16 alternative
circumstances, the network portion includes a network entity 25 that is
17 suitable
for routing communications to/from VoIP communication devices. In such
18
circumstances, the network entity 25 could be a softswitch and the packet-
based
19 application
server 30 could be a different softswitch, or a dedicated server for
performing the functionality that will be described in more detail herein. For
example,
21 the network
entity 25 can be the MCS 5200 Soft Switch manufiictured by Nortel
22 Networks
Limited of 8200 Dixie Road, Brampton, Ontario L6T 5P6, Canada,
23 although it
should be appreciated that this is but one non-limiting example among
24 many possibilities within the scope of the present invention.
26 In a
further alternative, in the case where a communication device, such as
27 communication device 12 includes both PSTN and IP capabilities (such as a
28 broadband
phone), the communication device could be connected to more than one
29 network
portion. For example, in such a case, communication device 12 could be
connected to both network portion 18 and network portion 22.
31
32 It should
be appreciated that the PSTN network 18, the wireless network 20 and the
33 data
network 22 can be operated and managed by different service providers or
34
alternatively can be managed by the same service provider. As mentioned above,
the
5
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 network portions 18, 20 and 22 enable the communication devices 12 14 and
16 to
2 reach, or be reached by, any of various other communication devices
(which are not
3 shown for the sake of simplicity).
4
More specifically, although Figure 1 shows only one POTS communication device
12,
6 one wireless communication device 14 and one VoIP communication device
16, it
7 should be appreciated that the communication architecture 10 is suitable
for enabling
8 communication between hundreds of thousands of communication devices, if
not
9 more. In addition, each of the network portions 18, 20 and 22 is capable
of supporting
significantly more communication devices than just the ones shown in Figure 1.
11
12 Although only one packet-based application server 30 is shown in Figure
1, it will be
13 appreciated that the communication architecture 10 can also include
multiple
14 interconnected packet-based applications servers. In such cases, the
multiple
interconnected packet-based application servers may communicate with one
another
16 over physical or wireless links, so as to share information and complete
the routing of
17 calls.
18
19 As mentioned above, in accordance with the present invention, a
communication link
can be established between a packet-based application server 30 and POTS
21 communication devices (such as POTS phone 12), wireless communication
devices
22 (such as wireless communication device 14) and VoIP communication
devices (such
23 as VoIP phone 16). As such, communications that originate from the PSTN
24 communication device 12, the wireless communication device 14 or from
the VoIP
communication device 16, can be processed and/or routed to the appropriate
26 destination by the packet-based application server 30.
27
28 In order for the packet-based application server 30 to be able to
communicate with the
29 PSTN, wireless and VoIP communication equipment, the communication
architecture
10 includes gateways 19, 21 and 23 between the packet-based application server
30
31 and the network portions 18, 20 and 22. Gateways 19, 21 and 23 enable
32 communication and interoperability between the different network
portions 18, 20 and
33 22 and the packet-based application server 30. Gateways are known in the
art, and as
34 such will not be described in more detail herein.
6
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1
2 As shown in the example of Figure 1, the packet-based application server
30
3 comprises a communication unit 32 and a processing unit 34. In addition,
the packet-
4 based application server 30 is communicatively coupled to a database 28.
The packet-
based application server 30 is operative to interact with the database 28 in
order to
6 effect various telephony processing operations, such as when a
communication device
7 originates an outgoing call, receives an incoming call or participates in
a call in
8 progress. As mentioned above, having the packet-based application server
30 process
9 and route communications from POTS, wireless and VoIP communication
devices
provides additional functionality and flexibility that is not possible with
the more
11 traditional switching entities. For example, the packet-based
application server 30 can
12 enable voice recognition, such that a user of a communication device
does not need to
13 physically dial a phone number in order to initiate a call. Instead, the
user can simply
14 verbalize the call destination information, which can be detected and
recognized by
the packet-based application server 30 in order to process the call. In
addition, the
16 packet-based application server 30 may include functionality to
interrupt a call that is
17 in progress in order to provide certain information to a user of a
communication
18 device that is engaged in the active call. The packet-based application
server 30 may
19 also facilitate features such as three-way, or multi way, calling, among
others.
21 The packet-based application server 30 comprises suitable hardware,
firmware,
22 software, control logic, or a combination thereof for implementing its
functionality. In
23 accordance with a specific non-limiting example of implementation, the
packet-based
24 application server 30 is a softswitch. For example, the packet-based
application server
30 can be the MCS 5200 Soft Switch manufactured by Nortel Networks Limited of
26 8200 Dixie Road, Brampton, Ontario L6T 5P6, Canada, although it should
be
27 appreciated that this is but one non-limiting example among many
possibilities within
28 the scope of the present invention.
29
As mentioned above, although only one packet-based application server 30 is
shown
31 in Figure 1, in reality, each of the network portions 18, 20 and 22 can
be in
32 communication with multiple different packet-based application servers
30 either
33 directly or indirectly. As such, a given communication device may not
always
34 establish a communication link with the same packet-based application
server 30.
7
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 Instead, a communication device may establish a communication link with a
different
2 packet-based application server depending on certain circumstances. For
example, in
3 the case of a POTS phone that operates within a fixed geographical
location, it is
4 possible that the POTS phone will always establish a communication link
with the
same packet-based application server 30 when a telephony action is initiated
and
6 needs to be processed. Alternatively, it's also possible that if the
usual packet-based
7 application server is handling a large call volume at a particular time
then the POTS
8 phone may establish a communication link with a different packet-based
application
9 server that is handling less call load. In yet a further alternative, a
different packet-
based application server may be used for its ability to deliver the feature or
call
11 treatment required. In a non-limiting embodiment, not all packet based
application
12 servers may offer the same processing features, or be able to service
all of the
13 subscribers to a given service. For example, some packet based
application servers
14 might only service certain subscribers or be able to perform certain
Iiinctionalities.
16 In the case of a wireless phone that is mobile and that is able to roam
to different
17 regions, depending on where the wireless phone is at any given time, a
18 communication link may be established with different packet-based
application
19 servers. For example, a communication link may be established with the
packet-based
application server that is in closest proximity to the phone, with a packet-
based
21 application server that is handling the smallest call volume, or with a
packet-based
22 application server that can handle a subscriber's telephony features.
23
24 The manner in which a communication link is established between a packet-
based
application server, such as packet-based application server 30, and a
communication
26 device (such as communication device 12 or communication device 14) will
now be
27 described in more detail below with respect to the method shown in
Figure 2. As
28 described below in a non-limiting example, the method may be performed
by the
29 network entity (either network entity 24, 25 or 26) that is responsible
for
switching/routing calls within each network portion 18, 20, 22. In the case
where a
31 call, or an attempt to initiate another type of telephony action, is
being made by a
32 PSTN communication device (such as POTS communication device 12), then
it is
33 network entity 24 that will perform the method of causing a
communication link to be
34 established between the communication device and the packet-based
application
8
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 server 30. Likewise, in the case where the call, or an attempt to
initiate another type of
2 telephony action, is being made by a wireless communication device (such
as wireless
3 communication device 14), then it is network entity 26 that will perform
this method.
4 In the case where the call, or attempt to initiate another type of
telephony action, is
being made by a VoIP communication device (such as VoIP communication device
6 16), then it is network entity 25 that will perform this method.
7
8 Firstly, at step 200, the method involves receiving over a network
connection a signal
9 from a communication device indicative of an intention to initiate at
telephony action.
The indication of an intention to initiate a telephony action could be an
indication of
11 an intention to place a call, an indication of an intention to send an
SMS, IM or other
12 text message, an intention to initiate a video call, or an indication of
an intention to
13 check voice mail, among other possibilities. Other telephony actions not
mentioned
14 here are also included within the scope of the present invention.
16 In the case where the signal indicative of an intention to initiate a
telephony action is
17 generated by a PSTN communication device, such as POTS communication
device
18 12, the signal is typically received by the network entity 24. As
mentioned above, the
19 network entity 24 can be a DMS switch, or any other suitable network
equipment for
routing calls, or other communications, in a PSTN environment. In the case
where the
21 signal indicative of an intention to initiate a telephony action is
generated by a
22 wireless communication device, such as wireless communication device 14,
the signal
23 is typically received by the network entity 26. The network entity 26
can be a mobile
24 switching center, or any other equipment suitable for routing calls in a
wireless
environment.
26
27 This signal indicative of an intention to initiate a telephony action
can be generated in
28 a variety of different ways. For example, in the case of POTS
communication device
29 12, or VoIP communication device 16 the signal can be generated by
simply lifting
the phone's receiver off the hook, such that the phone goes into an "off hook"
31 condition. Alternatively, the signal may be generated by activating a
user-operable
32 input on the communication device, which could be a dedicated feature
button on the
33 POTS communication device 12, or a "send button" or other dedicated
feature button
34 on the wireless communication device 14. It should be appreciated that
the user
9
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 operable input does not necessarily require a conscious button-press by
the subscriber,
2 either. In an alternative embodiment, the user operable input could be
triggered based
3 on a predictive behavioral event, such as opening a clamshell phone, or
sensing the
4 proximity of the phone to the subscriber's face (such as in the case
where a user will
issue a voice-command rather than using their dial-pad). In yet another
embodiment,
6 the signal indicative of an intention to initiate a telephony action
could be generated
7 based on a user providing biometric identification, among other
possibilities. The
8 signal indicative of an intention to initiate a telephony action, which
typically is
9 indicative of an intention to place a call, is transmitted over a network
connection
from the communication device to the appropriate network entity. For the sake
of
11 simplicity, the indication of an intention to initiate a telephony
action is described
12 below as being an intention to place a call.
13
14 The signal indicative of an intention to make a call may also provide
the network
entity with an identification of the communication device that generated the
signal. In
16 this manner, the network entity will know which communication de vice
generated the
17 signal indicative of the intention to make a call. The identification of
the
18 communication device may be provided by including a unique identifier
associated
19 with the communication device. The unique identifier may be a phone
number, an
electronic serial number (ESN), an IP address or a Uniform Resource Identifier
(URI)
21 associated with the communication device, among other possibilities.
22
23 At step 202, once the signal has been received at the network entity,
the method
24 involves causing a communication link between the communication device
and the
packet-based application server 30 to be established. As will be described in
more
26 detail below, this communication link can be established by directly
contacting an
27 appropriate packet- based application server 30 in the case where the
destination of
28 the packet-based application server is known, or by issuing a request
for the
29 destination of an appropriate packet-based application server 30 and
establishing the
connection once a response to the request has been received. Each of these
scenarios
31 will be described in more detail below.
32
33 Once the communication link between the packet-based application server
and the
34 communication device is established, the packet-based application server
30 is able to
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 receive communication destination information for the intended call (or
information
2 related to a desired telephony action) directly from the communication
device. As
3 such, the packet- based application server 30 can receive communication
destination
4 information from the communication device. The communication destination
information can be a phone number associated with a destination communication
6 device, such that when the calling party wishes to call or send an SMS,
IM or other
7 text message to the destination communication device, the phone number
can be
8 entered into the calling party's communication device. Alternatively, in
the case
9 where a user wants to check his/her voicemail, the communication
destination
information could be a mailbox number or a password, for example. The call
11 destination information can be provided to the packet-based application
server 30 via
12 dialed DTMF tones, dialed wireless CDMA or GSM packets, dialed VoIP
packets, or
13 alternatively via voice information entered at the communication device.
For example,
14 in the case where the communication destination information is entered
via voice
information, the user may simply utter phrases such as "call Johnny",
"Voicemail" or
16 the user may recite digits such as"514 777 1234". The call destination
information
17 may also come from a digital source stored on the communication device
or retrieved
18 from the network via an address book selection or data based service
information
19 exchange.
21 As mentioned above, the method described with respect to Figure 2 is
generally
22 performed by either the network entity 24 (in the case where the
intended call is being
23 made by a PSTN communication device), the network entity 26 (in the case
where the
24 intended call is being made by a wireless communication device) or the
network
entity 25 (in the case where the intended call is being made by a VoIP
communication
26 device). Shown in Figure 3 is a non-limiting functional block diagram of
a network
27 entity in accordance with the present invention. Although for the
purposes of
28 simplicity, Figure 3 shows network entity 24, it should be appreciated
that the
29 network entity shown in Figure 3 could just as easily be network entity
25 or 26.
Anything described herein with respect to network entity 24 is also applicable
to
31 network entity 25 or 26.
32
33 As shown, network entity 24 includes a detection unit 40 and a call
routing unit 42. In
34 addition, the network entity 24 is in communication with a database 44,
which may or
11
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 may not be part of network entity 24. The database 44 may contain call-
processing
2 information, among other possible information. The detection unit 40 is
operative for
3 receiving the signal indicative of an intention to make a call, or to
initiate another
4 telephony action, from a given communication device. Once the detection
unit 40 has
detected the signal, the call routing unit 42 is operative for routing the
intended call
6 through the communication architecture 10. In certain cases, and as will
be described
7 below in more detail, the call routing unit 42 is operative for causing a
communication
8 link between the packet-based application server 30 and the communication
device to
9 be established, such that a call can be processed by the packet-based
application
server 30.
11
12 A call can be routed through the packet-based application server 30 when
the
13 communication device is a subscriber to a "packet-based routing
feature". The
14 "packet-based routing feature" enables outgoing calls that are made by
the subscribing
communication device to be processed and routed through the packet-based
16 application server 30. A list of communication devices and whether or
not they
17 subscribe to the "packet-based routing feature" can be stored in the
database 44 or, for
18 example, in a presence server that can be queried by the network entity.
In an
19 alternative embodiment, the "packet-based routing feature" may be a
feature that is
offered to all communication devices, regardless of whether they subscribe to
this
21 feature. In such a case, a database comprising a list of subscribers to
the packet-based
22 routing feature is not necessary.
23
24 It should be appreciated that the network entity 24 (as well as network
entities 25 and
26) comprises suitable hardware, firmware, software, control logic, or a
combination
26 thereof for implementing its functionality, including the functionality
of the detection
27 unit 40 and the call routing unit 42. In some embodiments, the network
entity 24 (or
28 the network entities 25 and 26), the database 28, and the one or more
packet-based
29 application servers 30 may reside in a common network element of the
communication architecture 10. In such embodiments, links between these
31 components may be physical (i.e., wired or wireless) links or logical
links. In other
32 embodiments, different ones of the network entity 24 (or the network
entities 25 and
33 26), the database 28, and the one or more packet-based application
servers 30 may
34 reside in different or common network elements of the communications
architecture
12
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 10 that are interconnected via one or more physical links and possibly
other elements
2 (e.g., gateways) of the communications architecture 10. Also, although it
is depicted
3 in Figure 3 as being one component, the database 44 may be distributed in
nature, i.e.,
4 it can have portions of its content stored in different memory units
possibly located in
different network elements of the communications architecture 10. For example,
call
6 processing information may be stored in a memory unit dedicated to
storing this
7 information and distinct from a memory unit that stores information
relating to call
8 feature subscriber information.
9
A more detailed explanation of the method of Figure 2 will now be explained
with
11 respect to the flow chart of Figure 4 and the representative diagram of
Figure 5. It
12 should be appreciated that the process shown in Figure 4 is performed by
the network
13 entity 24 in the case where the intended call is being made by a POTS
phone, by the
14 network entity 26 in the case where the intended call is being made by a
wireless
phone and by network entity 25 in the case where the intended call is being
made by a
16 VoIP phone 16. As such, each step of this process will first be
described generally,
17 and then with respect to each of network entity 24, 25 and 26 since the
details
18 surrounding each step of this process will be different depending on
whether the step
19 is being performed by network entity 24 in a PSTN environment, network
entity 26 in
a wireless environment or network entity 25 in a VoIP environment.
21
22 Firstly, at step 400, the network entity detects an intention to make a
call from a
23 communication device. This detection occurs at the detection unit 40 of
the network
24 entity.
26 In the case of network entity 24 or 25, this detection occurs upon
receipt of a signal
27 from a POTS phone or VoIP phone indicative of an intention to make a
call. As
28 described above, this signal may be sent to the network entity 24 (or
25) when the
29 phone receiver is lifted, such that the phone goes "off hook".
Alternatively, the signal
may be sent to the network entity 24 (or 25) in response to the actuation of a
user
31 actuated input, such as a feature button being pressed.
32
33 In the case of network entity 26, this detection may occur upon receipt
of a signal
34 from a wireless phone indicative of an intention to make a call. Given
that wireless
13
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 phones do not go "off hook" in the traditional manner, the signal may be
sent to the
2 network entity 26 when the user presses the "send/talk" button, opens a
clamshell,
3 places the phone close to his/her face, or when a specific feature button
is activated. In
4 the case of wireless phones, the signal indicative of an intention to
make a call
generally requires some form of user involvement, although this is not
necessary.
6
7 Once a signal indicative of an intention to make a call is received at
the detection unit
8 40 of the network entity, the call routing unit 42 of the network entity
proceeds to step
9 402. The process performed at step 402 is the same regardless of whether
it is
performed by network entity 24, network entity 25 or network entity 26. During
step
11 402, the call routing unit 42 determines whether the communication
device from
12 which the signal was received is a subscriber to the "packet-based
routing feature". As
13 mentioned above, the signal indicative of the intention to make a call
includes a
14 unique identifier associated with the communication device that
generated the signal.
As such, in order to determine whether the communication device is a
subscriber to
16 the "packet-based routing feature", the network entity (either network
entity 24 or 26)
17 accesses the database 44 which includes a record of all the
communication devices
18 that have subscribed to the "packet-based routing feature". This may be
done by
19 comparing the unique identifier of the communication device received
with the signal
against a list of communication devices contained within the database that are
21 identified as being subscribers to the packet-based routing feature.
22
23 In the case where the network entity determines that the communication
device that
24 generated the signal indicative of an intention to make a call is not a
subscriber to the
"packet-based routing feature", then the call routing unit 42 will proceed to
step 404
26 wherein the call is processed in a traditional manner. In the case where
a
27 communication device includes a dedicated "packet-based feature button"
but the user
28 does not subscribe to the "packet-based routing feature", if a user
accidentally presses
29 this button, the user could be presented with a message similar to
"Sorry but you are
not subscribed" or "sorry, please contact us to enable this feature", among
various
31 other possibilities.
32
33 In the case of network entity 24 that operates in the PSTN environment,
a call that
34 originates from a POTS communication device that is not a subscriber to
the "packet-
14
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 based routing feature" will be routed by the DMS switch in a traditional
manner.
2 More specifically, the DMS switch may use traditional switching equipment
in order
3 to route the call to another POTS communication device. Alternatively,
the routing of
4 the call may be done across multiple different network environments
depending on
the type (and, in some cases location) of the communication device to which
the call
6 is destined. For example, in the case where the POTS communication device
12 is
7 calling wireless communication device 14, the call will be routed through
a gateway
8 into the wireless network, such that the mobile switching center (network
entity 26)
9 can complete the routing to the wireless communication device 14.
11 In the case of network entity 26 that operates in a wireless
environment, a call that
12 originates from a wireless communication device that is not a subscriber
to the
13 "packet based routing feature" will be routed by the mobile switching
center in the
14 traditional manner. More specifically, the mobile switching center may
use traditional
switching equipment in order to route the call to another wireless
communication
16 device. Alternatively, the routing of the call may be done across
multiple different
17 network environments depending on the type (and, in some cases location)
of the
18 communication device to which the call is destined. For example, in the
case where
19 the wireless communication device 14 is calling POTS communication
device 12, the
call will be routed through a gateway into the PSTN network, such that the DMS
21 switch (network entity 24) can complete the routing to the POTS
communication
22 device 12.
23
24 As such, in the case where a communication device is not a subscriber to
the "packet-
based routing feature", the calls originating from that communication device
will be
26 routed using traditional switching functionality, and without using the
packet-based
27 application server 30. This routing between networks is illustrated by
dashed lines in
28 Figure 1.
29
However, in the case where the network entity (either network entity 24, 25 or
26)
31 determines at step 402 that the communication device that issued the
signal indicative
32 of an intention to make a call is a subscriber to the "packet-based
routing feature",
33 then the call routing unit 42 of the network entity will proceed to step
406.
34
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 It should be appreciated that in the case where the "packet-based routing
feature" is
2 provided to all communication devices, and not just to those that
subscribe to this
3 feature, then steps 402 and 404 can be removed from the process, and the
method
4 would jump directly from step 400 to step 406.
6 It will be appreciated that there are multiple ways for a given network
entity to
7 establish a communication link with a packet-based application server. In
a first case,
8 the network entity knows the destination of the packet-based application
server to
9 which the communication device should be connected, prior to receiving a
signal from
a communication device indicative of an intention to make a call. In other
words, the
11 network entity knows which packet-based application server to contact in
order to
12 establish a communication link, and knows how to contact that packet-
based
13 application server.
14
In a second case, when the network entity receives the signal indicative of an
intention
16 to make a call, it is not aware of the destination of an appropriate
packet-based
17 application server with which a communication link with the
communication device
18 can be established. As such, in this second case, the network entity
performs a
19 brokering procedure, wherein the network entity issues a request for the
destination of
an appropriate packet-based application server upon receipt of a signal
indicative of
21 an intention to make a call from a communication device. As used herein,
the term
22 "brokering procedure" refers to the process of issuing a request for the
destination of
23 an appropriate packet-based server with which the communication device
can
24 establish a communication link, and only establishing the link upon
receipt of the
destination from an external entity. In an alternative embodiment that will
not be
26 described in detail herein, instead of the brokering procedure being
performed by one
27 of the network entities, it may be performed by alternative hardware
and/or software
28 contained within the network portions 18, 20 and 22.
29
In light of these two situations, namely the situation where the destination
of an
31 appropriate packet-based application server is known, and the situation
where the
32 destination needs to be determined, at step 406, the call routing unit
42 of the network
33 entity (either network entity 24, 25 or 26) determines whether the
destination of an
16
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 appropriate
packet-based application server is known. This can be determined, for
2 instance, by accessing information stored within the database 44.
3
4 For
example, the database 44 may include destination information associated with
one
or more appropriate packet-based application servers to which a communications
link
6 for a given
communication device can be established. The database 44 may also
7 include
information indicative of which packet-based application server to use in a
8 given
situation. For example, it may be desirable to connect to different packet-
based
9 application
servers at different times of the day, or on different days of the week. In
addition, the database 44 may include a table specifying which packet-based
11 application
server is suitable for which communication device. This determination
12 may be
based upon geography, telephony features available or subscribed to, or
13 service provider, among other possibilities.
14
In the case where the database does not include destination information
associated
16 with one or
more appropriate packet-based application servers, then the database may
17 include
program instructions for performing the brokering procedure. The program
18
instructions may include the destination of a local packet-based application
server, a
19 a
centralized or other network entity to which a destination request signal can
be sent.
This will be described in more detail below.
21
22 In the case
where the destination information of a packet-based application server is
23 known prior
to receipt of the signal from a communication device indicative of an
24 intention
to make a call, the network-entity will proceed to step 408. For the sake of
example, let us assume that the known packet-based application server is
packet-
26 based
application server 30 shown in Figure 1. At step 408, the network entity
27 contacts
the packet-based application server 30 at the known destination so as to
28 establish a
communication link between the packet-based application server and the
29 communication device. This scenario is illustrated as "case 1" in Figure
5.
31 The
destination information of the packet-based application server 30 may be a
32 telephone
number or an IP address, among other possibilities. As such, once the signal
33 indicative
of an intention to make a call is received at the network entity (as
illustrated
34 by line 50
in Figure 5), the network entity issues a connection request to the packet-
17
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 based
application server 30 (as illustrated by line 52). The connection request may
be
2 made, for
example, by dialing the telephone number associated with the packet-based
3 application
server 30 and providing information to the packet-based application server
4 30 that may
be needed in order to establish the communication link. For example, the
connection request 50 may include information such as the identifier of the
6
communication device with which a communication link should be established,
and
7 an
identifier of the network entity, among other possible information. Upon
receipt of
8 the
connection request at the packet-based application server 30, a communication
9 link is established between the packet-based application server 30 and the
communication device (shown by line 54). This communication link may be
11 established
by a handshaking procedure that takes place between the packet-based
12 application
server 30 and the communication device, or between the packet-based
13 application
server 30, the network entity and the communication device. Once the
14
communication link is established, the packet-based application server 30 can
receive
call destination information for the intended call from the communication
device so as
16 to be able to process the intended call.
17
18 Steps 406
and 408 can be performed by the network entities 24, 25 and 26. For
19 example,
network entity 24 may know the destination of packet-based application
server 30 so as to be able to cause a communication link to be established
between
21 PSTN
communication device 12 and packet-based application server 30. Likewise,
22 network
entity 26 may also know the destination of packet-based application server
23 30 so as to
be able to cause a communication link to be established between wireless
24 communication device 14 and the packet-based application server 30.
26 Although
step 408 which involves contacting the packet-based application server 30
27 at a
destination that is known prior to receiving a signal indicative of an
intention to
28 make a call
can be performed in both the PSTN and wireless environment, it will be
29 appreciated
that step 408 may particularly be common in the PSTN environment. In a
PSTN environment, the PSTN communication equipment, such as POTS
31
communication device 12, generally remain within a limited geographical area.
As
32 such, the
closest packet-based application server 30 to the POTS communication
33 device 12
generally will not change. As such, it makes sense that the POTS
34
communication device could always connect to the same packet-based application
18
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 server 30. In such a circumstance the local network entity 24, which
could be a DMS
2 switch, would already know the destination information for the packet-based
3 application server 30, which could be stored in database 44, for example.
4
With reference to Figure 5, it should be appreciated that the receipt of the
signal
6 indicative of an intention to make a call (line 50) and the issuing of
the connection
7 request (line 52) can be done almost instantaneously by the network
entity such that
8 establishment of a communication link between the communication device
and the
9 packet-based application server is transparent to the user. As such, a
user of the
communication device is generally unaware of the process that is being
performed to
11 establish the communication link with the packet-based application
server 30. From
12 the user's perspective, as soon as the user picks up the phone, or
activates the
13 "feature" button associated with the "packet-based routing feature", the
14 communication device is connected to the packet-based application
server.
16 Referring back to Figure 4, at step 406, when the destination of an
appropriate packet-
17 based application server with which a communication link can be
established is not
18 known prior to receipt of the signal from the communication device
indicative of an
19 intention to make a call, the network entity will proceed to step 410,
wherein it begins
the brokering procedure. As mentioned above, during the brokering procedure,
the
21 network entity issues a request for the destination of an appropriate
packet-based
22 application server. This brokering procedure can be performed by either
network
23 entity 24, network entity 25 or network entity 26 depending on whether
the
24 communication device that issues the signal indicative of an intention
to make a call is
a POTS communication device, a VoIP communication device or a wireless
26 communication device.
27
28 At step 410, the network entity (24, 25 or 26) issues a destination
request for a packet-
29 based application server that is operative for processing the intended
call from the
communication device. This scenario is illustrated as "case 2" in Figure 5.
31
32 As mentioned above, although only one packet-based application server 30
is shown
33 in Figure 1, the communication architecture 10 can include multiple
interconnected
34 packet-based applications servers. The multiple packet-based application
servers are
19
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 each able to
communicate with each other, so as to share information and complete
2 the routing
of calls. Links between these packet-based application servers may be
3 physical links (i.e., wired or wireless) or logical links.
4
As such, upon receipt of the signal indicative of an intention to make a call
(line 56 in
6 Figure 5)
the network entity sends a destination request (line 58) to either the local
7 packet-based
application server 30, or to a centralized or other network entity (which
8 will be
described in more detail below). The destination request can be issued by
9 sending a
signal-based query message (such as a subscribe/notify or AN query) to the
local packet-based application server, or to the centralized or other network
entity.
11
12 The
destination request that is issued by the network entity may include, for
example,
13 information
such as the unique identifier of the communication device that would like
14 to make a
call, the geographical location of that communication device and the service
provider of the communication device. Regardless of what entity (whether the
local
16 packet-based
application server 30 or a centralized or other network entity) receives
17 the
destination request, that entity is able to determine an appropriate packet-
based
18 application
server for handling the intended call. This determination can be made on
19 the basis of
the destination request and the information contained therein, as well as
on other factors that are known to the entity that is making the
determination. For
21 example, the
determination may be made based on the geographical location of the
22
communication device that intends to make a call, such that a communication
link is
23 established
with a packet-based application server that is in closest proximity to the
24
communication device. The determination may also be made on the basis of the
call
volume being handled by each of the packet-based application servers in the
26
communication architecture 10, such that a communication link is established
with a
27 packet-based
application server that is handling a low volume of calls at the given
28 time. In
accordance with a further example, the determination may be made on the
29 basis of the
service provider of the communication device that intends to make the
call, or on the basis of the processing features and services subscribed to by
the user
31 of the
communication device. In the case where the determination is made by the local
32 packet-based
application server 30 (or another packet-based application server having
33 the same
structure as packet-based application server 30) the information required to
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 make the determination of an appropriate packet-based application server
may, for
2 example, be stored in the database 28 shown in Figure 1.
3
4 For example, database 28 may include information indicative of the
geographical
location of each of the packet-based application servers 30 in the
communication
6 architecture 10, and/or information indicative of the types of subscriber
7 features/services that can be facilitated by given packet-based
application servers. The
8 database 28 may also be continually updated, such that it includes
information
9 regarding the call volume being handled by each of the packet-based
application
servers in the communication architecture 10.
11
12 Although it is depicted as being one component in the example of Figure
1, the
13 database 28 may be distributed in nature, i.e., it can have portions of
its content stored
14 in different memory units possibly located in different network elements
of the
communications architecture 10. For example, the call processing in formation
may be
16 stored in a memory unit dedicated to storing this information and
distinct from a
17 memory unit that stores information required for determining an
appropriate packet-
18 based application server in response to a destination request. In
addition, each packet-
19 based application server in the communication architecture 10 may
include a separate
database 28, or they may each refer to the same database 28 for accessing the
21 information for facilitating the determination of an appropriate packet-
based
22 application server.
23
24 Once a determination of an appropriate packet-based application server
has been
made, the destination information for that packet-based application server is
then
26 returned to the network entity (line 60 shown in Figure 5), such that
the network
27 entity can contact that packet-based application server at the received
destination in
28 order to cause a to communication link between the communication device
and the
29 appropriate packet-based application server be established.
31 To better illustrate this brokering procedure, let us take, for example,
the case where
32 the wireless communication device 14 generates a signal indicative of an
intention to
33 make a call. As shown in Figure 1, that signal will be received by
network entity 26,
34 which can be, for example, a mobile switching center contained within
the wireless
21
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 network portion 20. Given that the wireless communication device 14 is
mobile and
2 can move around, it may not make sense for a communication link to always
be
3 established with the same packet-based application server. More
specifically, in the
4 case where the wireless phone 14 has traveled a far distance from its
home territory, it
may make sense for a different packet-based application server to handle a
call (or
6 another attempted telephony action) originating from the wireless
communication
7 device 14. As such, in the case where the wireless communication device
14 is a
8 subscriber to the "packet-based routing feature", upon receipt at the
network entity 26
9 of a signal from the wireless phone 14 indicative of an intention to make
a call (or
attempt another telephony action), the network entity 26 determines that it
does not
11 know the destination of an appropriate packet-based application server
to service the
12 wireless device 14, and as such issues a destination request.
13
14 In accordance with a first example of implementation, the network entity
26 may send
the destination request to the wireless communication device 14's local (or
home
16 territory) packet-based application server 30. This can be done by
issuing a signal-
17 based query to a local packet-based application server 30 via a SIP, AN
or IP
18 address. Upon receipt of the destination request, the local packet-based
application
19 server 30 will determine an appropriate packet-based application server
with which
the wireless phone 14 can establish a communication link. As mentioned above,
this
21 determination may be made based on the current geographical location of
the wireless
22 communication device 14, the services provided by a given packet-based
application
23 server, the features subscribed to by the wireless device and the call
load being
24 handled at each of the packet-based application servers in the
communication
architecture 10. For example, the local packet-based application server 30 may
26 provide the destination of the packet-based application server that is
in closest
27 proximity to the wireless communication device 14, or alternatively, may
provide the
28 destination of the packet-based application server that is currently
handling the least
29 amount of calls from other communication devices. It should be
appreciated that other
criteria for determining an appropriate packet-based application server are
also within
31 the scope of the present invention. For example, an appropriate packet-
based
32 application server may be determined on the basis of the service
provider of the
33 wireless communication device 14.
34
22
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 In accordance with a second example of implementation, the network entity
26 may
2 send the destination request to a centralized entity. The centralized
entity may be one
3 or a plurality of other packet-based application servers. Alternatively,
the centralized
4 entity may be a dedicated request handling entity that is operative to
field destination
requests from hundreds of thousands of other communication devices, and
designate
6 an appropriate packet-based application server for each destination
request. The
7 centralized entity can be contacted via a signal-based query. As such, no
matter where
8 the wireless communication device is located, it will not be complicated
to contact the
9 centralized entity. In the case where the centralized entity is a
plurality of packet-
based application servers, the signal-based destination request query can be
11 simultaneously sent to towards all of the packet-based application
servers via an
12 intermediate load-balancer/load-sharing element which will decide which
individual
13 packet-based application server to which to send the destination
request.
14
Upon receipt of the destination request, the centralized entity will determine
an
16 appropriate packet-based application server with which the wireless
communication
17 device 14 can establish a communication link. This determination may be
made based
18 on the geographical location of the wireless communication device 14 and
the call-
19 load capacity at each of the packet-based application servers in the
communication
architecture 10, among other possibilities.
21
22 Although the above example has been illustrated with respect to wireless
23 communication device 14, step 410 could also have been described with an
example
24 in the PSTN and VoIP environments.
26 Regardless of whether the destination request is handled by a local
packet-based
27 application server 30, or a centralized entity, once the determination
of an appropriate
28 packet-based application server has been made, the destination
information associated
29 with the appropriate packet-based application server is sent to the
network entity 26
(this is illustrated by line 60 in Figure 5). Therefore, at step 412, upon
receipt of the
31 destination of an appropriate packet-based application server, the
network entity
32 issues a connection request to the appropriate packet-based application
server (as
33 illustrated by line 62). The issued connection request is made by
contacting the
34 appropriate packet-based application server at the destination provided
in response to
23
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 the destination request. This may be done by dialing a telephone number
indicated in
2 the received destination information. The connection request may also
include any
3 information needed by the appropriate packet-based application server to
establish the
4 communication link with the communication device. For example, the
connection
request may include information such as the identifier of the communication
device
6 and/or the identifier of the network entity, among other possible
information.
7
8 Upon receipt of the connection request at the appropriate packet-based
application
9 server, a communication link is established between the appropriate
packet-based
application server and the communication device (line 64 of Figure 5) such
that the
11 packet-based application server can receive communication destination
information
12 (or information related to a desired telephony action) from the
communication device.
13 This communication link may be established by a handshaking procedure
that takes
14 place between the packet-based application server and the communication
device, or
between the packet-based application server, the network entity and the
16 communication device.
17
18 As previously mentioned, the brokering process described above with
respect to steps
19 410 and 412 in Figure 4 can be performed by the network entity 24, the
network entity
25 or the network entity 26 depending on the type of communication device that
has
21 indicated an intention to made a call. The brokering procedure involves
a sequence of
22 signals being sent back and forth between the network entity and either
the local
23 packet-based application server 30 or a centralized entity, in order to
receive an
24 indication of an appropriate packet based application server with which a
communication device can establish a communication link.
26
27 With reference to Figure 5, it should be appreciated that the brokering
process
28 described above and shown with respect to lines 58, 60 is performed
almost
29 instantaneously. As such, a user of the communication device is
generally unaware of
the brokering process that is being performed to establish the communication
link
31 with an appropriate packet-based application server. From the user's
perspective, as
32 soon as the user picks up the phone, or activates a "feature" button
associated with the
33 "packet-based routing feature", the communication device is connected to
the packet-
34 based application server.
24
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1
2 In an alternative embodiment, instead of the brokering process being
performed by a
3 network entity, the brokering process can be performed directly by the
4 communication device itself. This will now be described in more detail
with respect to
the flow chart shown in Figure 6, and "case 3" illustrated in Figure 5. For
the
6 purposes of simplicity, the process shown in Figure 6 will be described
with respect to
7 the wireless communication device 14. However, it should be appreciated
that a
8 similar process could also be described with respect to PSTN
communication devices,
9 such as POTS communication device 12, and VoIP communication devices.
11 In the case where the brokering procedure is performed by the wireless
12 communication device 14, at step 600, the wireless communication device
14 detects
13 an intention to initiate a telephony action which, for the purposes of
example only,
14 will be described herein as an intention to make a call. The detection
of the intention
to make a call can be detected by an application resident on the communication
16 device. Furthermore, in the case where the brokering procedure is
performed by the
17 communication device, the communication device must have some internal
18 processing capabilities as well as a data connection (i.e. IP, CDMA,
GSM, EDGE,
19 EVDO, WiMax, WiFi etc). For example, the communication device may be any
one
of a wireless communications device, POTS phone with an IP connection, VoIP
21 phone or computer equipped with a VoIP soft client.
22
23 The detection of the intention to make a call by the application
resident on the
24 communication device may be based on a variety of factors. For example,
in the case
of wireless communication device 14, the detection can take place when a
feature
26 button or the "send/talk button" is activated, when a clamshell is
opened, or a specific
27 application can be launched, among other possibilities. In the case of a
VoIP or
28 broadband phone, the intention to make a call can be detected when the
phone
29 receiver is lifted off the hook, or when a specific feature button Is
pressed. In this
case, the application may monitor for detection of the off-hook condition. In
other
31 cases, launching of the specific application would indicate an intention
to make a call.
32
33
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 Once the intention to make a call has been detected by the application
resident at the
2 wireless communication device 14, the application issues a destination
request (line
3 66 in Figure 5). In the same manner as described above, this destination
request can
4 be sent to either the local packet-based application server 30 or to a
centralized entity,
which could be one or a plurality of other packet-based application servers or
a
6 request handling entity. The request handling entity may be operative to
field
7 destination requests from tens of thousands or hundreds of thousands (if
not more) of
8 other communication devices, and designate an appropriate packet-based
application
9 server for each request.
11 In a non-limiting example, upon detection of an intention to make a call
(or initiate
12 another telephony action), the application issues a destination request
to a network-
13 based application or server (that stores or has access to a database of
destination
14 information for packet-based application servers of the type previously
described)
over the data connection (using a a URL or IP address link) for an appropriate
packet-
16 based application server to which the present communication device
should be
17 connected. In the case of a wireless communication device, issuing of
the destination
18 request (via accessing a link provided by a URL or IP address) by the
application
19 resident on the communication device may result in an interface being
presented to
the user for supplying his/her current location so that destination
information for an
21 appropriate packet-based application server (based on current location,
for example)
22 may be determined. Alternatively, the location of a
subscribing wireless
23 communication device may be tracked on a continual basis such that
issuance of the
24 destination request (via accessing a link provided by a URL or IP
address) by the
application results in the wireless communication device being provided with
26 destination information for an appropriate packet-based application
server (based on
27 current location, for example) without any user input. In yet a further
alternative, the
28 wireless communication device may be updated by a network-based
application or
29 server on a regular basis (e.g. at regular time intervals) with
destination information of
an appropriate packet-based application server to which a communication link
should
31 be established. In any case, destination information for an appropriate
packet-based
32 application server is determined by the network-based application or
server and
33 returned to the communication device via the data connection. It will
readily be
34 appreciated that a similar process for retrieving destination
information for an
26
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 appropriate packet-based application server may be followed when the
2 communication device is a VoIP phone, a POTS phone with an IP connection
or a
3 computer equipped with a VoIP softclient.
4
When a wireless phone makes a destination request directly to an application
server,
6 the destination request is passed through the mobile switching center, in
order to get
7 switch logic to route the destination request to the packet-based
application server or
8 the centralized entity. In such circumstances, the mobile switching
center operates in a
9 traditional manner.
11 The destination request that is issued by the application resident on
the wireless
12 communication device 14 asks for the destination of an appropriate
packet-based
13 application server with which the wireless communication device 14 can
establish a
14 communication link. The destination request may include information such
as the
unique identifier of the wireless communication device 14, the geographical
location
16 of the wireless communication device 14 at that time, and the service
provider of the
17 wireless communication device 14. Any other information that is suitable
for helping
18 the local packet-based application server 30, or the centralized entity,
determine an
19 appropriate packet-based application server with which a communication
link can be
established can also be included in the destination request.
21
22 Once the determination of an appropriate packet-based application server
has been
23 made, the destination information associated with that appropriate
packet-based
24 application server is sent to the wireless communication device 14 (line
68 in Figure
5). The appropriate packet-based application server may be determined based on
a
26 variety of factors, such as its proximity to the wireless communication
device 14, the
27 telephony features or services it is able to provide, or based on the
call load that is
28 currently being handled. It should be appreciated that a variety of
other factors can be
29 used to determine an appropriate packet-based application server with
which the
wireless communication device 14 can establish a communication link.
31
32 At step 604, upon receipt of the destination information of an
appropriate packet-
33 based application server, the wireless communication device 14 issues a
connection
34 request to the appropriate packet-based application server (as
illustrated by line 70 in
27
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 Figure 5). This connection request can be passed through the respective
network
2 entity (e.g. a mobile switching center). The connection request may be
made, for
3 example, by dialing a telephone number indicated in the received
destination
4 information or by forwarding a signal-based request. The connection
request can also
forward to the packet-based application server any information needed to
establish the
6 communication link. For example, the connection request may include
information
7 such as the unique identifier of the communication device and its current
geographical
8 location, among other possible information.
9
Upon receipt of the connection request at the appropriate packet-based
application
11 server, a communication link is established between the packet-based
application
12 server and the communication device (line 72 in Figure 5). This may be
achieved via
13 a handshaking procedure between the packet-based application server and
the wireless
14 communication device 14 (which could be performed with a network entity
as an
intermediary). Once the communication link is established, the packet-based
16 application server can receive call destination information (or
information related to
17 another telephony action) from the wireless communication device 14.
More
18 specifically, using the example cited above, once a communication link
has been
19 established, the packet-based application server is able to receive
destination
information for the intended call from the communication device.
21
22 In accordance with the present invention, the destination information
for the intended
23 call (or information related to another telephony action) is not entered
into the
24 communication device until the communication link with the packet-based
application
server has been established. In this manner, when the user enters the
destination
26 information into the communication device, it is received at the packet-
based
27 application server as it is being entered into the communication device.
28
29 It will be appreciated that the destination information for an intended
call (or
information related to another telephony action) may be entered into the
31 communication device by dialing DTMF tones, forwarding CDMA or GSM
packets,
32 or by entering voice information. In the case of POTS communication
device 12, once
33 the communication link with a packet-based application server has been
established,
34 the packet-based application server will "hear" the DTMF tones as they
are being
28
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 dialed into the communication device. For example, in the case of DTMF
tone
2 collection, the DTMF tones can be collected via an inband procedure,
wherein the
3 DTMF tones are passed through the media path as sounds (both PSTN and
cell
4 networks can do this), or the DTMF tones can be collected via an out-of-
band
procedure, wherein the DTMF tones are sent via non media signals (such as CDMA
6 or GSM packets, SIP messaging, etc...). In the case of a wireless
communication
7 device 14, the packet-based application server will "receive" the CDMA or
GSM
8 packets as they are being generated. This may be done by receiving
signaling in the
9 network similar to SIP. Finally, in the case where the user enters the
call destination
information via voice information, which can be done at either the POTS
11 communication device 12, the wireless communication device 14, or the
VoIP phone
12 16, the packet-based application server will "hear" the voice
information as it is being
13 entered. In this manner, much of the functionality and flexibility in
call handling that
14 is provided by packet-based application servers can be applied to calls
made through
traditional PSTN and wireless communication equipment.
16
17 In the above-described methods of establishing a communication between a
18 communication device and a packet-based application server, it is the
client who
19 initiates the start of establishing the connection request. In
alternative embodiments
that are not described in detail herein, it is possible that the packet based
application
21 server could establish and maintain a constant connection with the
communication
22 device such that the packet based application server actively listens
for a client to
23 provide an indication of an intention to initiate a telephony action.
This type of
24 constant monitoring may be established, for example, when a
communication device
is detected as present on the network.
26
27 Those skilled in the art will appreciate that, in some embodiments,
certain
28 functionality of a given component described herein (including the
network entities 24
29 and 26 and the packet-based application server 30) may be implemented as
pre-
programmed hardware or firmware elements (e.g., application specific
integrated
31 circuits (ASICs), electrically erasable programmable read-only memories
32 (EEPROMs), etc.) or other related elements. In other embodiments, a given
33 component described herein (including the network entities 24 and 26 and
the packet-
34 based application server 30) may comprise a processor having access to a
code
29
CA 02710199 2010-06-18
WO 2009/079735
PCT/CA2007/002346
1 memory which stores program instructions for operation of the processor
to
2 implement functionality of that given component. The program instructions
may be
3 stored on a medium which is fixed, tangible, and readable directly by the
given
4 component (e.g., removable diskette, CD-ROM, ROM, fixed disk, USB key,
etc.).
Alternatively, the program instructions may be stored remotely but
transmittable to
6 the given component via a modem or other interface device connected to a
network
7 over a transmission medium. The transmission medium may be either a
tangible
8 medium (e.g., optical or analog communications lines) or a medium
implemented
9 using wireless techniques (e.g., microwave, infrared or other wireless
transmission
schemes).
11
12 While specific embodiments of the present invention have been described
and
13 illustrated, it will be apparent to those skilled in the art that
further modifications and
14 variations can be made without departing from the scope of the invention
as defined
in the appended claims.
