U.S. patent application number 13/096834 was filed with the patent office on 2011-08-18 for multiple protocol communications.
Invention is credited to John M. Cooney, Andre Milota, Darius Mostowfi, Albert Papp, III, Anthony Zalenski.
Application Number | 20110200184 13/096834 |
Document ID | / |
Family ID | 30118057 |
Filed Date | 2011-08-18 |
United States Patent
Application |
20110200184 |
Kind Code |
A1 |
Zalenski; Anthony ; et
al. |
August 18, 2011 |
MULTIPLE PROTOCOL COMMUNICATIONS
Abstract
A particular method includes receiving a dialing code from a
calling device at a customer premise device coupled to the calling
device. The method also includes selecting a telecommunication
protocol based at least in part on a network of a receiving device.
The method further includes initiating a call to the receiving
device using the selected telecommunication protocol.
Inventors: |
Zalenski; Anthony; (Boca
Raton, FL) ; Papp, III; Albert; (Mountain View,
CA) ; Cooney; John M.; (San Carlos, CA) ;
Milota; Andre; (Oakland, CA) ; Mostowfi; Darius;
(San Carlos, CA) |
Family ID: |
30118057 |
Appl. No.: |
13/096834 |
Filed: |
April 28, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10613656 |
Jul 3, 2003 |
7957401 |
|
|
13096834 |
|
|
|
|
10354527 |
Jan 30, 2003 |
|
|
|
10613656 |
|
|
|
|
60394207 |
Jul 5, 2002 |
|
|
|
Current U.S.
Class: |
379/229 |
Current CPC
Class: |
H04L 65/1006 20130101;
H04L 65/1069 20130101; H04L 69/18 20130101; H04L 65/1009 20130101;
H04L 29/06027 20130101; H04L 65/104 20130101; H04L 69/12
20130101 |
Class at
Publication: |
379/229 |
International
Class: |
H04M 7/00 20060101
H04M007/00 |
Claims
1. A method comprising: receiving a dialing code from a calling
device at a customer premise device coupled to the calling device;
determining a network of a called device based on the dialing code;
selecting a telecommunication protocol based at least in part on
the network of the called device; and initiating a call to the
called device using the selected telecommunication protocol.
2. The method of claim 1, wherein, when the dialing code comprises
a predetermined prefix, the network of the called device is a same
network as a network of the calling device and the call is
initiated as an on-network call.
3. The method of claim 1, wherein the dialing code is preceded with
and followed by a first non-numeric symbol.
4. The method of claim 3, further comprising receiving a personal
identification code from the calling device.
5. The method of claim 4, wherein the personal identification code
is separated from the dialing code by a second non-numeric symbol
that is different from the first non-numeric symbol.
6. The method of claim 1, wherein initiating the call comprises
interacting with a service provider network device, wherein the
service provider network device performs call set up signaling on
behalf of the calling device to establish the call, and wherein the
calling device and the called device communicate without the
service provider network device after the call is established.
7. The method of claim 1, wherein initiating the call using the
selected telecommunication protocol comprises: selecting a
telecommunication protocol template by a processor of the customer
premise device, wherein the telecommunication protocol template
includes one or more virtual machine instructions executable by a
virtual machine at the customer premise device to implement the
selected telecommunication protocol; reading a first virtual
machine instruction of the telecommunication protocol template from
a first memory device of the customer premise device; initializing
a first finite state machine using the first virtual machine
instruction, wherein the telecommunication protocol template
includes first template state data defining a first template state
of the first finite state machine; and storing the first template
state at a second memory device of the customer premise device in a
first state table, wherein the second memory device is internal to
the processor.
8. The method of claim 7, further comprising: receiving an input at
the processor via the call; determining, by the virtual machine, an
updated template state of the first finite state machine based on
the first state table and the input; and storing an updated first
state table at the second memory device, the updated first state
table specifying the updated template state.
9. The method of claim 7, further comprising: receiving a request
at the processor to implement a second telecommunication protocol;
reading a second virtual machine instruction from the first memory
device; initializing a second finite state machine using the second
virtual machine instruction; and storing a second template state of
the second finite state machine at the second memory device in a
second state table.
10. The method of claim 7, wherein the first memory device is a
FLASH memory device and the second memory device is a RAM memory
device.
11. The method of claim 1, wherein the selected telecommunication
protocol includes at least one of a Session Initiation Protocol
(SIP), a H.323 protocol, a STUN protocol, and a dynamic host
configuration protocol (DHCP).
12. A method comprising: receiving a signal from a telephony device
coupled to a customer premise equipment telephony gateway during a
call between the telephony device and a remote telephony device via
the customer premise equipment telephony gateway; in response to
the signal, interrupting the call at the customer premise equipment
telephony gateway; initiating a second call to a second remote
telephony device from the customer premise equipment telephony
gateway; sending information from the customer premise equipment
telephony gateway to a second telephony gateway, wherein the second
telephony gateway is a customer premise device coupled to the
remote telephony device, wherein the information notifies the
second telephony gateway of the second call; and sharing data among
the telephony device, the remote telephony device and the second
remote telephony device via the call and the second call.
13. The method of claim 12, wherein the signal comprises a hook
flash.
14. The method of claim 13, wherein the hook flash enables access
to a control protocol of the customer premise equipment telephony
gateway via the telephony device.
15. The method of claim 12, wherein initiating the second call
comprises: selecting a telecommunication protocol template by a
processor of the customer premise equipment telephony gateway,
wherein the telecommunication protocol template includes one or
more virtual machine instructions executable by a virtual machine
at the customer premise equipment telephony gateway to implement a
telecommunication protocol; reading a first virtual machine
instruction of the telecommunication protocol template from a first
memory device of the customer premise equipment telephony gateway;
initializing a first finite state machine using the first virtual
machine instruction, wherein the telecommunication protocol
template includes first template state data defining a first
template state of the first finite state machine; and storing the
first template state at a second memory device of the customer
premise equipment telephony gateway in a first state table, wherein
the second memory device is internal to the processor.
16. A communication system comprising: a service provider gateway
configured to communicate with one or more telephony gateways,
including a first telephony gateway and a second telephony gateway,
via a switched packet network, the service provider gateway
comprising: a network communication system to communicate via the
switched packet network; a protocol handling system to process data
communicated according to a selected telephony protocol; a bridge
system to connect the first telephony gateway to the second
telephony gateway in response to data received from the first
telephony gateway; and a billing system to facilitate billing
users.
17. The communication system of claim 16, wherein the service
provider gateway is further configured to communicate with one or
more telephones via a public switched telephone network.
18. The communication system of claim 16, wherein the service
provider gateway further includes an interactive voice response
system to automatically respond to billing questions.
19. The communication system of claim 16, wherein the service
provider gateway further comprises an authentication system to
authenticate a user of the first telephony gateway.
20. The communication system of claim 16, wherein the service
provider gateway is configured to determine whether a call
initiated via the first telephony gateway is an on-network call
based on a portion of a dialing code received at the first
telephony gateway.
Description
CLAIM OF PRIORITY
[0001] This application is a continuation of and claims priority to
U.S. patent application Ser. No. 10/613,656 filed Jul. 3, 2003,
which is a continuation in part of U.S. patent application Ser. No.
10/354,527 filed Jan. 30, 2003, which claims priority to
Provisional Application No. 60/394,207 filed Jul. 5, 2002. Each of
the above referenced applications is incorporated by reference
herein, in their entirety, for all purposes.
FIELD OF THE DISCLOSURE
[0002] The present disclosure relates generally to implementation
of communication protocols.
BACKGROUND
[0003] Less than thirty years ago, the term "telecommunications"
connoted making and receiving telephone calls over the public
switched telephone network (PSTN). Today, telecommunications means
transporting data representing voice, video, text, and instructions
over wired and wireless digital networks such as the Internet.
[0004] Within the PSTN telephony environment the equipment needed
to support the telecommunications infrastructure was centralized at
a telephone company "central office" so that Customer Premises
Equipment (CPE) could be limited to simple telephones. The nature
of modern digital networks is to decentralize many functions and
capabilities thus requiring more complex CPE to provide access.
However, subscribers expect newer digital telecommunications to be
usable with the same ease as the traditional telephone and at low
cost. This expectation dictates that the digital network interfaces
and associated protocols be compact and unobtrusive, implemented
inexpensively, and require little in the way of subscriber
interaction.
[0005] The complexity of implementing a CPE for digital
telecommunications comes primarily from the need to implement the
protocols used to organize information sent over digital networks.
These protocols evolved in rich computing environments with many
computing resources (e.g., central processing unit (CPU) power for
computation; memory for data and program storage). Additionally,
the protocols evolved quickly (i.e., in months or years, vs. the
traditional PSTN years or decades), reflecting knowledge gained
from actual application. The CPE for digital communications of
today must, therefore, have an effective way to deal with protocol
implementation within the restricted computational resources
dictated by the CPE's restricted hardware cost.
[0006] What would be useful is a system and method for implementing
multiple digital telecommunication protocols on a reduced hardware
CPE that is not limited to any specific protocol.
SUMMARY
[0007] A particular embodiment is a telecommunications gateway that
implements telecommunication protocols using a telecommunication
protocol engine (TPE). Telecommunication protocols include multiple
digital networking protocols (e.g., Session Initiation Protocol
(SIP), H.323, DHCP, TCP/IP and STUN protocol) and telephony
protocols. However, the present disclosure is not so limited. As
will be apparent to those skilled in the art, any protocol that
facilitates telecommunications over digital networks (both between
digital devices, a digital device and an analog device, and between
analog devices) may be implemented by the TPE without departing
from the scope of the present disclosure.
[0008] In this embodiment, the TPE is implemented using
inexpensive, memory limited microprocessors and inexpensive flash
memory. However, this is not meant as a limitation. As will be
apparent to those skilled in the art, embodiments may be
implemented in other computing contexts without departing from the
scope of the present disclosure.
[0009] Therefore, an aspect of the present disclosure is an
implementation of a telecommunication protocol engine (TPE) using a
memory limited microprocessor and flash memory.
[0010] Another aspect of the present disclosure is an
implementation of a (TPE) using a "virtual machine" that executes
instructions from flash memory.
[0011] Another aspect of the present disclosure is the
representation of telecommunication protocols as Finite State
Machine (FSM) abstractions.
[0012] Still another aspect of the present disclosure is the
implementation of a virtual machine to support FSMs used to express
protocol implementation.
[0013] A further aspect of the present disclosure is the
implementation of FSMs using virtual machine instructions stored in
a flash memory, wherein the virtual machine instructions represent
telecommunication protocols implemented as states, instructions,
and transitions.
[0014] Yet another aspect of the present disclosure is a CPE
Control Protocol that specifies how an end user can control the
behavior of the CPE using a standard telephone that may be
connected directly to the CPE or that accesses the CPE
remotely.
[0015] An aspect of the present disclosure is a telephony gateway
including a TPE.
[0016] Another aspect of the present disclosure is the
implementation of the Session Initiation Protocol (SIP), H.323
protocol, DHCP and STUN protocol as FSM.
[0017] These and other aspects of the present disclosure will
become apparent from a review of the general and detailed
descriptions that follow. A particular embodiment is a
telecommunications gateway that implements multiple digital
networking protocols using a telecommunication protocol engine
(TPE). In this embodiment, the TPE is implemented using
inexpensive, memory limited microprocessors and inexpensive flash
memory. However, this is not meant as a limitation. As will be
apparent to those skilled in the art, particular embodiments may be
implemented in other computing contexts without departing from the
scope of the present disclosure.
[0018] A finite state machine (FSM) execution facility is
implemented using virtual machine instructions located in the flash
memory. The "state" of a given instance of a FSM is located in the
RAM and accessed by the microprocessor. As the virtual machine
executes instructions from the flash memory, it modifies the FSM
state in RAM along with accessing other facilities of the
microprocessor and other software resources.
[0019] Another embodiment includes a method for representing a
protocol as a FSM using an extension of the C++ programming
language. Specifically, an FSM specification may be created on a
development computer using C++ with a specialized library. The
result is a program that, when executed on the development
computer, produces virtual machine instructions that can be loaded
into the flash memory of the TPE. The virtual machine within the
TPE microprocessor then uses these instructions as described above.
While this embodiment uses the C++ programming language and a C++
library, the present disclosure is not so limited. As will be
appreciated by those skilled in the art, other programming
languages (and related libraries) may be used to produce virtual
machine instructions that define an FSM.
[0020] An additional aspect of the present disclosure is the
specification of a CPE Control Protocol that is implemented using
the technique described above. This protocol specifies how an end
user can control the behavior of the CPE using a standard telephone
that may be connected directly to the CPE or accessing the CPE
remotely by "calling" over either a Voice over Internet Protocol
(VoIP) or PSTN connection. This protocol allows the user to direct
the CPE to place a local telephone to VoIP call; a local telephone
to local PSTN call or a received VoIP call routed to the local PSTN
based call. Additionally, this protocol allows the user to modify
other operations of the CPE.
[0021] The CPE Control Protocol receives input from the user via
the standard telephone touch-tone keypad. Specifically, the user
enters a pound-sign (#), a sequence of digits or stars identifying
the operation with any related data and a terminating pound-sign
(#) indicating the end of user input. The CPE Control Protocol
communicates with the user via one or more facilities depending on
the originating location of the command. These include: flashing of
light-emitting diodes (LEDs) on the CPE; generation of tones played
over the telephone; voice commands played over the telephone;
placing a call back to the telephone; and using a "Caller ID"
mechanism to present alpha numeric data via the telephones Caller
ID display facility.
BRIEF DESCRIPTION OF THE DRAWINGS
[0022] FIG. 1A illustrates a functional block diagram of a
telecommunication protocol engine according to an embodiment.
[0023] FIG. 1B illustrates a functional block diagram of a
telecommunication protocol according to an embodiment.
[0024] FIG. 1C illustrates a function block diagram showing data
flows in a telecommunication protocol engine according to an
embodiment.
[0025] FIG. 2 illustrates a flowchart of a process for implementing
a telecommunication according to an embodiment.
[0026] FIG. 3 illustrates means for expressing a finite state
machine (FSM) according to an embodiment.
[0027] FIG. 4 illustrates a Voice over Internet Protocol (VoIP)
telecommunication between a caller and a called party from the
perspective of the caller according to an embodiment.
[0028] FIG. 5 illustrates a script created using a scripting
language to implement the protocol illustrated in FIG. 4.
[0029] FIG. 6 illustrates a block diagram of a telephony gateway
according to an embodiment.
[0030] FIG. 7 illustrates a service offering according to an
embodiment.
[0031] FIG. 8 illustrates a service provider gateway according to
an embodiment.
DETAILED DESCRIPTION
[0032] A particular embodiment is a telecommunications gateway that
implements multiple protocols using a telecommunication protocol
engine (TPE). In this embodiment, the TPE is implemented using an
inexpensive, memory limited microprocessor and inexpensive flash
memory. A finite state machine (FSM) execution facility is
implemented in firmware using virtual machine instructions located
in the flash memory. The "state" of a given instance of a FSM is
located in the RAM and accessed by the microprocessor. As the
virtual machine executes instructions from the flash memory, it
modifies the FSM state in RAM along with accessing other facilities
of the microprocessor and other software resources. However, this
is not meant as a limitation. As will be apparent to those skilled
in the art, particular embodiments may be implemented in other
computing contexts without departing from the scope of the present
disclosure.
[0033] Referring to FIG. 1A, a block diagram of a TPE 100 according
to an embodiment is illustrated. The TPE 100 includes
microprocessor 102 and flash memory 140. The microprocessor 102
includes a central processing unit (CPU) 120, random-access memory
(RAM) 115, and firmware 105 in which a virtual machine 125 resides.
The CPU 120 runs the virtual machine 125 and communicates with the
flash memory 140 over a data bus 110. In the preferred embodiment,
the data bus 110 is a parallel bus, but this is not meant as a
limitation. In another embodiment, the data bus 110 is a serial
bus. The flash memory 140 holds protocol templates for protocol A
145, protocol B 155, and protocol N 160 and data relating to each
protocol. Each protocol template includes virtual machine
instructions 150 defining one or more finite state machines (FSMs)
implementing a particular protocol, illustrated only for protocol A
145. The RAM 115 may include finite state machine (FSM)
instructions.
[0034] A protocol template provides specifications for the one or
more FSMs that represent a single protocol. Each FSM specification
is used to generate a set of virtual machine instructions 150 that
define a FSM implementing all or a portion of a particular
protocol.
[0035] FIG. 1B illustrates a functional block diagram of a
telecommunication protocol according to an embodiment. Protocol A
145 includes the virtual machine instructions 150. The virtual
machine instructions 150 for protocol A 145 define a first finite
state machine 161, a second finite state machine 162, and an Nth
finite state machine 163. Thus, a single protocol may include more
than one finite state machine. Telecommunication protocols include
multiple digital networking protocols (e.g., Session Initiation
Protocol (SIP), H.323, dynamic host configuration protocol (DHCP),
transmission control protocol/internet protocol (TCP/IP) and
session traversal utilities for network address translation (STUN)
protocol) and telephony protocols. However, the present disclosure
is not so limited. As will be apparent to those skilled in the art,
any protocol that facilitates telecommunications over digital
networks (both between digital devices, a digital device and an
analog device, and between analog devices) may be implemented by
the TPE without departing from the scope of the present
disclosure.
[0036] The virtual machine instructions 150 are read and executed
on demand by a virtual machine that resides in the firmware 105.
Since the microprocessor 102 (see FIGS. 1A and 1C) retrieves
instructions in response to a request from the virtual machine 125,
only a tiny portion of an entire protocol specification
(specifically one virtual machine instruction and its associated
operands) is stored in the RAM 115 at any given time. One advantage
of this arrangement is that the RAM 115 contains only the currently
executing virtual machine instruction and data, and a few
miscellaneous data structures needed for representing the current
FSM states (also fixed in size). The content of the flash memory
140--which can be quite sizeable if it implements a number of
complex protocols--does not utilize any significant portion of the
RAM 115. The size of the virtual machine instructions 150 is
limited by the amount of flash memory 140 available, and has no
significant impact on the RAM 115 resources. This allows complex
protocols to be implemented on very low cost microcontroller
architectures in which program and data memory is very limited but
flash memory is plentiful.
[0037] FIG. 1C illustrates a function block diagram showing data
flows in the telecommunication protocol engine 100 according to an
embodiment. The bus references have been deleted for clarity. A
protocol creation system 175 produces the virtual machine
instructions 150. In an embodiment, the protocol creation system
175 includes a C++ development environment that is used to encode
an FSM specification for a protocol as human readable text. The
resulting C++ program is then executed to generate the virtual
machine code that is store in the flash memory 140 via I/O ports
165 and I/O bus 170 (FIG. 1A). While this embodiment uses the C++
programming language and a C++ library, the present disclosure is
not so limited. As will be appreciated by those skilled in the art,
other programming languages (and related libraries) may be used to
produce virtual machine instructions that define a FSM.
[0038] A virtual machine instruction 150 and its operands are
retrieved, by the CPU 120 at the direction of the virtual machine
125 and stored in RAM 115 for execution. Virtual machine 125 then
executes the instruction that was retrieved.
[0039] A telecommunication protocol is implemented in accordance
with the process embodiment illustrated in FIG. 2. A call is made
to the TPE to implement a telecommunication protocol, at 200. The
call is processed, at 205, by the microprocessor via the TPE
software, which determines, at 210, which telecommunication
protocol is to be implemented and where the protocol template
resides in flash memory, at 215. FSM data is then created in RAM
and initialized to represent the state of the FSM used to implement
the protocol, at 220. The virtual machine then starts executing
instructions from a location within the flash memory based upon the
FSM data, at 225.
[0040] The classic definition of a FSM is a collection of states.
When a FSM is being executed, it is said to be "in" a specific
state waiting for an event. When an event occurs, the FSM
definition asserts a next state to be entered. When a state is
entered a set of actions may performed, then the FSM waits in that
state for the next event. This FSM operational model is implemented
directly by the virtual machine described above in reference to
FIG. 1B and supported by the specialized virtual machine
instructions generated from the FSM that expresses the protocol.
Specifically, the State entry actions are expressed as specialized
virtual machine instructions. Additional the virtual machine is
capable of executing multiple FSM at the same time be they multiple
instances of one FSM definition or different FSM definitions. It is
through this facility that the TPE supports multiple protocols
concurrently.
[0041] The virtual machine in this embodiment is specially designed
to operate with events modeled as "tokens" so that it can respond
to both physical events identified by the microprocessor firmware
or logical events generated by other FSMs being concurrently
executed in a uniform manner. The representation of "tokens" and
their management further enhances the TPE to operate on very low
cost microprocessor architectures in which program and data memory
is very limited.
[0042] Virtual machine instructions are generated using a
"translator" that receives human-readable syntax and translates
this syntax to FSM instructions. To facilitate the specification of
a protocol in human readable form and support its maintenance as
the protocol evolves over time, the translator and virtual machine
support the concept of shared state entry instructions through
function or macros. These are collections of virtual machine
instructions that reside in the flash memory, along with FSM
specifications. As required, the virtual machine can execute these
special collections of instructions upon demand.
[0043] FIG. 3 illustrates a means for expressing FSM according to
an embodiment. Referring to FIG. 3, a function name is associated
with a purpose. These function name/purpose pairs are used to
author protocol implementations via FSM definitions. A function
name/purpose pair (referred to as an "Advocate") corresponds to a
facility "known" to the virtual machine that is implemented in the
firmware. While this exemplary embodiment uses the C++ programming
language, the present disclosure is not so limited. As will be
appreciated by those skilled in the art, other programming
languages may be used to produce virtual machine instructions that
define a FSM.
[0044] The C++ definition of each Advocate includes code that
produces the appropriate virtual machine instructions that will be
placed into the flash memory. Note that some Advocates take
parameters. The task of setting up virtual machine instructions for
accessing and updating these parameters is also performed by C++
code within the body of the Advocate.
[0045] FIG. 4 illustrates a VoIP telecommunication protocol
according to an embodiment between a caller and a called party from
the perspective of the caller. FIG. 5 illustrates a script
according to an embodiment created using the scripting language
(FIG. 3) to implement the protocol illustrated in FIG. 4. The
caller initiates a call, at 400, causing the FSM to send a message
to the called party, at 410. Referring to FIG. 5, the initial state
of the FSM is "CALL INITIATED." The FSM then receives signaling
messages via the network from the called party indicating the
response (status) of the called party, at 420. If the called party
is busy, the FSM receives a CALLED PARTY BUSY condition (referred
to as an event), at 430, executes a PLAY BUSY TONE command (an
action), at 460, and enters a "BUSY TONE" state, at 475. Similarly,
if there is no response from the called party and the call times
out, at 420, the FSM receives a TIME OUT condition, at 440,
executes a PLAY FAST BUSY TONE command, at 470, and enters a "FAST
BUSY TONE" state, at 485. If the call is delivered, the FSM
receives a CALL DELIVERED condition, at 450, executes both an "Init
Vocoder" and "Send (CONNECT_ACK)" instruction, at 465, and enters a
"Voice" state, at 480.
[0046] FIG. 6 illustrates a block diagram of a telephony gateway
600 according to an embodiment. A digital signal processor (DSP)
603 communicates with a CPU 610 over a host interface/API 605.
Power to the telephony gateway 600 is provided via a power supply
615. The DSP 603 communicates with a subscriber line interface
(SLI) 620 that offers connection to consumer premises equipment
through a first external jack 625. The SLI 620 interfaces with
customer premises equipment, such as a telephone. The DSP 603
communicates with a data access arrangement (DAA) 635 that offers
connection to a public switched telephone network (PSTN) through a
second external jack 637.
[0047] The CPU 610 is connected to a RAM 650, to a flash memory
640, and to a firmware unit 660. Together, the CPU 610, the RAM
650, the flash memory 640, and the firmware unit 660 include a
telecommunication protocol engine as described in the context of
FIG. 1. The CPU 610 also provides an interface to I/O ports 630. In
an embodiment, the I/O ports 630 include a serial interface and an
Ethernet interface. The I/O ports 630 are accessible through a
third external jack 645. It is anticipated that as RAM becomes
cheaper and more capable of enhanced storage that the firmware unit
660 can also reside within the RAM 650.
[0048] FIG. 7 illustrates a service offering according to an
embodiment. Referring to FIG. 7, a service provider network 700
includes a service provider proxy 703, a service provider gateway
705 and connectivity to a public switched telephone network (PSTN)
740, an internet service provider (ISP)-A network 710, and an ISP-B
network 715. A telephony gateway-A 720 is in communication with the
ISP-A network 710. A telephone-A 725 is connected to the telephony
gateway-A 720. Similarly, a telephony gateway-B 730 is in
communication with the ISP-B network 715. A telephone-B 735 is
connected to the telephony gateway-B 730.
[0049] A connection between the telephony gateway (720,730) and its
associated ISP network (710, 715) is made by means known in the
art. By way of illustration and not as a limitation, the telephony
gateway-A 720 is in communication with the ISP-A network 710 using
DSL connection. The telephony gateway-B 730 is in communication
with the ISP-B network 715 via a dialup connection. It is
noteworthy that no general-purpose computer is required to
establish communication between the telephony gateway (720, 730)
and the service provider gateway 705.
[0050] Both the telephony gateway-A 720 and the telephony gateway-B
730 are registered with the service provider network 700. The
telephony gateway-A 720 may place a call to the telephony gateway-B
730 by interacting with the service provider network 700. The
service provider proxy 703 then contacts the telephony gateway-B
730 on behalf of the telephony gateway-A 720 to facilitate call
setup (also known in the art as signaling). Once the signaling has
been completed, the telephony gateway-A 720 interacts directly with
the telephony gateway-B 730 passing information until the call is
terminated. When the call is terminated, call tear down signaling
is performed through the service provider proxy 703.
[0051] Both the telephony gateway-A 720 and the telephony gateway-B
730 are registered with service provider network 700. The service
provider network 700 is also connected to the PSTN 740, which is
connected to a telephone-C 745 and a telephone-D 750. A call placed
by telephony gateway-A 720 to the telephone-C 745 via the PSTN 740
would involve call setup and tear down signaling between the
telephony gateway-A 720, the service provider proxy 703, and the
service provider gateway 705.
[0052] A call placed over the service provider network 700 is
routed by the service provider gateway 705. In an embodiment, the
protocol used by a telephony gateway (720, 730) and the routing is
controlled by a number dialed to initiate a telephone call via a
CPE Control protocol. By way of illustration and not as a
limitation, a call placed from the telephone-A 725 to the
telephone-B 735 is an "on-network" call, meaning both the calling
party and receiving party are using registered telephony gateways
(720, 730). In this embodiment, the telephone numbers associated
with registered telephony gateways begin with the same prefix, for
example 777. In this embodiment, the calling party using the
telephone-A 725 presses #777 (plus the remaining telephone number
digits)# on the telephone-A 725 (note that the starting and ending
pound-sings (#) reflect the requirements of the CPE Control
protocol). The service provider gateway 705 determines from the
prefix preceding the remaining telephone number digits that the
call is on-network and connects the telephone-A 725 to the
telephone-B 735 over the service provider network 700.
[0053] By contrast, if the telephone-A 725 places a call to the
telephone-C 745, the call is dialed using a standard prefix
(1+areacode+number) again bracketed by the pound-signs required by
the CPE Control protocol (e.g., #16503288459#).
[0054] As will be apparent to those skilled in the art, other
signaling conventions may be used to route telephone calls without
departing from the scope of the present disclosure.
[0055] In an embodiment, a service provider gateway is a
self-contained system for providing telephone communications using
telephony gateways as embodied herein. FIG. 8 illustrates a service
provider gateway according to an embodiment.
[0056] Referring to FIG. 8, a service provider gateway 800 includes
network communication systems 805 and protocol handling systems
815. These systems permit the service provider gateway 800 to
communicate with various networks using protocols required by the
networks or required by the type of communication service being
provided. Interactive voice response (IVR) software 830, in
combination with a billing system 835 and data management and
storage systems 850 gather billing data and automate billing
questions. Authentication of users is managed by an authentication
system 825.
[0057] In yet another embodiment, a service provider gateway 800
according an embodiment as described in reference to FIG. 8 is
licensed for use by a third party service provider (TPSP). In one
embodiment, the TPSP is permitted under the license to provide
service to subscribers using a telephony gateway as described
previously wherein the service is private labeled in the name of
the TPSP. In an alternate embodiment, the TPSP acquires franchise
rights to provide services to subscribers in the name of the
licensor. In still another embodiment, the TPSP is permitted to
offer access to a service provider network operated by the licensor
in the name of the TPSP.
[0058] In yet another embodiment, the telephony gateway is
configured to receive communications from a remote location via a
telephone call (either from the PSTN or a wireless service
provider). The communications may be used to configure the gateway
or to initiate a call from the gateway to a remote communication
device. In this latter embodiment, the gateway additionally
functions as a bridge between the incoming calling device and the
remote communication device. The gateway answers the incoming
calling, the CPE Control protocol accepts user input (e.g., an
authentication personal identification number (PIN), star and
target phone number: #65432*7771234567#) necessary to call the
remote receiving device, and then places a VoIP call to the remote
communication device.
[0059] In another embodiment, two telephony gateways are connected
to first and second communication devices respectively that are in
communication with each other. The first communication device sends
a "hook-flash" signal to the first telephony gateway. The first
telephony gateway suspends the communication with the second
telephony gateway and enables caller access to the CPE Control
protocol. Using this protocol the user directs the CPE to initiate
a three-way call to another phone. The CPE Control protocol will
notify the CPE Control protocol on the second device that a
three-way call has been initiated. The three-way connection
includes sharing data from one party with the other two parties on
the call. In this manner, a three-way connection is established and
maintained without external mixing devices or the need to deploy a
media gateway in the VoIP system.
[0060] The traditional VOIP architecture contained three layers: A
Signaling Layer, which converted signaling information between PSTN
protocols (such as CAS, SS7 or ISDN) and VOIP protocols (such as
MGCP, Megaco, or R323); a Switching Layer that routed and switched
VOIP calls to Signaling, Switching (for other systems) or the
Application layers; and an Application Layer, which provided
IP-centric enhanced voice services.
[0061] Prior to adopting H.323, there were few if any
interoperability standards. First-generation gateways were closed,
proprietary systems unique to each manufacturer. Few worked with
one another. While well suited to toll bypass applications, their
proprietary design severely limited their ability to interconnect
to carrier grade networks. Most could not support voice services
beyond toll bypass and debit card applications.
[0062] The subsequent generation VOIP call control architecture
used H.323 protocol to accomplish simple tasks like call
setup/control between gateways or billing/rating and routing
functions for multipoint networks. Call control software acted
simply as middleware that directed the media gateways as to how to
set up and tear down calls between gateways. Operating in real
time, the call control software kept track of which media gateways
were available, where they were located, and often determined how
to route calls over the network. Soft-switches evolved out of this
climate to overcome the limitations of the Media Gateway Control
Protocol (MGCP) and the media gateway controllers to support voice
services applications. Soft-switches are designed to support
PSTN/IP internetworking and signaling protocol mediation, (e.g.,
out-of-band SS7/C7, in-band R1, CAS, etc.) to switch calls and
control the media gateways in its domain through MGCP or Megaco,
and in addition, support application interfaces such as the Session
Initiation Protocol (SIP). This enabled a system to interact in
real-time with voice streams. Further, these enhancements allowed a
system to respond in real-time to detect dual-tone multi-frequency
(DTMF) or voice-recognition inputs and responses.
[0063] But these systems are incapable of handling DSP-intensive
media processing, for example, such as the type of processing
required to handle Interactive Voice Response (IVR) and
conferencing applications. Media Servers were introduced to handle
these tasks, but they created Quality of Service (QoS) problems.
This is because, streaming VOIP placed an entire application at the
mercy of the QoS level that an underlying IP network could provide.
Dropped packets because of instability of the underlying IP network
could negatively affect the overall QoS. Moreover, streaming cannot
support the basic, everyday telephony functions such as unified
messaging, store-and-forward faxing and other standard functions
that are needed today. This requires DSP-intensive media
processing, especially for in-band DTMF and fax tones. Further,
streaming solution could tax the system resources because the
system could be required to process a large number of small
packets, each containing the normal TCP/IP overhead.
[0064] In an illustrative architecture of a VOIP-enabled
telecommunication system, a calling party device--first Customer
Premise Equipment (CPE)--is coupled to a network, such as a packet
switched network (PSN), such as the Internet. A called party
device--second CPE--is coupled to the PSN.
[0065] Microgateway--a VOIP-Enabled CPE
[0066] In an aspect, the instant disclosure is directed toward a
CPE called a microgateway (MG), which connects telecommunication
terminal equipment such as a telephone handset to a PSN.
Microgateway could be connected to any other terminal device, such
as a desktop or a handheld personal computer, or a telephone
handset. Alternatively, a general-purpose server computer could be
coupled to the PSN, which computer is programmed suitably to
provide the functions of a microgateway (MG). Note that the
microgateway is not the same in form or function as a Media Gateway
or a VOIP gateway. Rather, microgateway is the name given to a CPE
device connected to a terminal device and configured to work as a
single port gateway, as will be explained in detail in the
following.
[0067] In an embodiment, microgateway includes a processor, some
memory and communication devices to couple the microgateway to a
network and to receive and transmit information in digital or
analog form. Additionally, where the terminal device coupled to the
microgateway is a telephone handset--which could be a digital or
analog telephone handset--the microgateway could connect to the PSN
via a telecommunication switch such as Lucent 5ESS.RTM. or
equivalent local office switch. Where the terminal device is a
mobile handset, it could be coupled to the PSN via a wireless
telecommunication network, and the details of how these connections
are established are known to persons of ordinary skill in the art
and need not be repeated here. The microgateway is configured to
interface with both Ethernet and dial-up VOIP lines. It is
understood that the first and the second CPEs (microgateways) are
connected to the PSN with an address such as a dotted-decimal
address used in IP addressing, for example, 121.255.48.16, which is
known to persons skilled in the art.
[0068] The microgateway could be implemented in the form of custom
hardware or in software. In a hardware implementation, the
microgateway includes custom-manufactured Application-Specific
Integrated Circuits (ASIC) that could be programmed with
application logic, and other supporting circuit elements, such as
digital signal processors (DSP) and memory devices to process
signals. These details will be explained with reference to
microgateway hardware architecture below.
[0069] In an embodiment, a block architectural diagram of the
microgateway contains a Digital Signal Processor (DSP), such as a
VP 1405; a Central Processor Unit (CPU), such as an IP2022 Network
Processor; memory, such as semiconductor memory; devices to
interface with a variety of input/output (I/O) or peripheral
devices, such as Ethernet, Serial I/O interface, Subscriber Line
Interface Card (SLIC), Data Access Arrangement (DAA), and the like;
and a suite of software programs, such as a Telephony Protocol
Engine and protocol stacks, such as H.323, SIP (for VOIP), TCP/IP,
Real Time Protocol (RTP), and V.34 soft modem programs. It should
be noted that the microgateway may be implemented totally in
software, where the critical DSP functions could be implemented as
software code executed in a general purpose processor such as a
Pentium III.RTM. microprocessor. It is assumed that the first and
the second CPEs are connected to the PSN either directly, via a
modem, or via another network, which other network could be a
mobile or PSTN or the like. The principles of the disclosure apply
equally well for all these variations.
[0070] A microgateway may be integrated into a VOIP architecture in
various forms (either in the form of a circuit board or in the form
of an AMC chip). For example, a microgateway may be coupled to a
traditional telephone and thereafter to both a PSN and the PSTN via
different interfaces, thereby making a "regular" PSTN telephone
call as well as a VOIP call (via the PSN) possible. In another
example, a low-cost dialup adapter may be coupled to the
microgateway enabling a connection to an ISP and a VOIP
telecommunication network. In another example, the microgateway
could be used to interface with a variety of telephony I/O devices,
such as an analog/digital wireline telephone handset, a cordless
telephone handset, and, via optional I/O ports, to a keypad such as
either a QWERTY keyboard or a DTMF keypad, and an LCD. In another
example, the microgateway (e.g., an ASIC chip) could be
incorporated into numerous devices.
[0071] A software architecture of the disclosed system includes a
transport layer such as the Transmission Control Protocol (TCP) or
the User Datagram Protocol (UDP) layer over an Internet Protocol
(IP) layer. It should be noted that this description provides only
an embodiment of the principles of the disclosed system and
therefore the principles should not be so limited. The IP layer may
be configured to function over an Ethernet (the protocol of choice
for local area networks) or a PPP interface (which is the protocol
of choice for a dialup ISP connection) layer. A network layer
(including the layers for Signaling, Call Control and Media
control) resides above the transport layer. A Media Gateway
Application Program Interface (Mg API) layer is configured above
the network layer. Application layer and the Telephony Protocol
Engine (TPE) layers reside above the network layer. An API layer
for customized user applications and DSP-intensive VOIP
applications (such as conference calling, three-way calling, etc)
resides above the Application layer. Standard telephony protocols
such as the G.168 (Echo Canceler), G.711, G.723 (Voice Codec),
G.729 and G.726 are also programmed within the microgateway. And
finally, codec drivers and interface software or firmware for SLIC,
DAA and other interfaces is also provided within the
microgateway.
[0072] Virtual Memory Subsystem
[0073] Traditional designs for telephony applications used multiple
processors and a shared main memory that stored data. Sometimes,
each processor may use a local cache to store its own private copy
of a subset of the data in the main memory. In this traditional
system, a separate memory control chip connecting the processors to
the main memory manages the operations necessary to access memory
from the processor. For example, if one of the processors makes a
reference to memory to access data, the control chip will schedule
a read for the data corresponding to the reference from the main
memory while simultaneously scheduling system probes to the other
processors to check for the presence of this address in the
processor cache.
[0074] In general, to establish a connection between the
microprocessor and the memory, the control chip uses 2*k pins with
k bits for each of two address buses, i.e., the address-out bus for
communicating the address of the memory reference from the
processor to the control chip, and the address-in bus used by the
control chip to send an address of a probe into each of the
processors. If k is large, the control chip can quickly become
pin-limited and cannot address a large amount of memory.
[0075] It is desirable to manage or address a large amount of
memory without the limitations imposed by low pin counts. Though
some large pin count processors exist, they are expensive. And
low-cost telephony applications, such as the disclosed VOIP
application, would benefit from a low pin count architecture, while
achieving a larger addressable memory via a virtual memory system.
It is generally known that a processor with a single address bus
for all memory size requirements will still require all the address
pins be connected to the control chip even though a lesser number
of pins are actually needed.
[0076] Thus, it is desired to reduce the pin count of the memory
control chip for a multiprocessor system with a limited memory size
requirement by providing a microprocessor which permits a designer
to select an address bus supporting one of a maximum memory size
requirement and a small memory size requirement.
[0077] In general, pin count limitation increases the number of
chips needed to emulate a particular logic design and thereby
decreases emulation speed, because signals must cross more chip
boundaries, and increases system cost. This is especially
pronounced in microcontroller chip designs where reducing the
overall cost is a critical factor.
[0078] The instant disclosure includes a method of overcoming pin
count limitations using a virtual memory system that uses a virtual
addressing scheme. VMS is built on a DSP/micro-controller and
allows in conjunction with the TPE to run high-level protocols,
such as H.323, which requires the ability to address a large amount
of memory.
[0079] Telephony Protocol Engine
[0080] The microgateway includes a Telephony Protocol Engine (TPE).
This TPE enables designing a system with protocol-independent
architecture, thereby enabling one to support a variety of
protocols, such as H.323. Additionally, using the TPE, one can
execute complex protocols on memory-limited and I/O (pin-limited)
micro-controllers or DSP chips.
[0081] The process of off-loading the state transitions, semantic
rules and language tokens to an external flash memory is called
uploading a template. In an aspect, rules of a protocol are
abstracted and stored on an auxiliary memory, which can be accessed
using a parallel bus or serial link that connects the auxiliary
memory to the TPE.
[0082] A protocol-independent machine can be built by adopting a
generalized state machine that can determine its next state from
the current state and an input. The protocol engine could use
generic tokens that represent each state, thereby enabling the
implementation of a variety of protocols with little complicated
coding. Additionally, the protocol engine could be stored in an
auxiliary memory, thereby enabling a designer to use the virtual
memory features to address a larger address space than is permitted
by the traditional pin-count limitations of a moderately priced
processor. Moreover, the auxiliary memory could be a volatile
memory (in which case the protocol engine should be loaded at power
up) or a non volatile memory (in which case the protocol engine
could be permanently burned into an EPROM or a Flash memory for
easy reuse).
[0083] In an embodiment, the architecture for the TPE and the VMS
both may be implemented entirely in hardware or in software. In
this embodiment, state information, semantic rules, tokens and data
tables that are necessary to execute a telephony protocol are
stored in an auxiliary memory device, such as the Atmel AT45DB011
flash memory. An aspect of the implementation is that the TPE
operates in conjunction with the main CPU, which executes program
instructions that act upon the state information, semantic rules,
rules and data tables to effect state transitions.
[0084] Common Channel Signaling to Setup and Manage VOIP Calls
[0085] Elements in the disclosed system, including the
microgateway, may also be configured to transport voice packets
over the SS7/C7 protocol. The SS7/C7 protocol allows the switch to
use out-of-band signaling. Out-of-band signaling refers to the
capability of the protocol to send signaling information separately
from the voice circuits. This greatly increases call processing and
trunk efficiency in the disclosed system as speed for a call set up
can be increased. Moreover, the disclosed system has the ability to
not use trunks if the called party phone is busy. The trunks that
would have been used to make the call can then be used to make
other calls. Further, the system designed herein provides the
ability to release calls to the previous gateways if the call fails
for a user-termination reason other than user-busy.
[0086] Remote Access and Control of Microgateway Via a Mobile
Telephone Handset
[0087] The disclosed microgateway is additionally configured to
receive communication from a remote location via a telephone call.
Such information may be used to configure, control and maintain the
microgateway, or to initiate additional calls from the
microgateway.
[0088] As stated above, the microgateway is equipped with a SLIC
and LAN or dialup VOIP interfaces, in addition to other interfaces.
A user operating a regular telephone handset may make a telephone
call into the microgateway by dialing a number designated to the
microgateway. In this case, the microgateway functions as a regular
telephone destination CPE, but the call terminates with the
microgateway. The user can then enter the required data to the
microgateway in order to initiate an outbound call from the
microgateway over the LAN or other VOIP connection. Advantageously,
the microgateway establishes a bridge connection to a second
destination, thereby allowing the user to communicate with a party
connected to the second destination. This is helpful in cases where
a user is out of his office or home, where the microgateway is
located. The user may wish to place an international call, but
doing so with his wireless connection may be prohibitive. In such a
case, the user may call his home or office microgateway and then
bridge a VOIP telephone call via the microgateway to the
international destination. This can help reduce the overall toll
for the call.
[0089] Three-Way VOIP Calling Using Peer-to-Peer Architecture
[0090] Also disclosed herein is a method for three-way calling
between VOIP clients using no external "media concentration" or
mixing device. Assume that two microgateways, a first microgateway
MG1 and a second microgateway MG2 are in voice communication with
each other, allowing a calling party to converse with a called
party in a manner described above. This could be similar to the
description of point-to-point communications between two
VOIP-enabled CPEs.
[0091] When one of the two parties in conversation, say, the
calling party, wishes to establish a three-way conference call,
which may include a third party, the party sends a hook-flash
signal to the microgateway to which it is connected. The
microgateway then acts as a switch, and suspends the call
temporarily and provides a dial tone to the party that sent the
hook-flash signal.
[0092] At or about the same time, MG1 allocates a register or other
service circuit and allocates a conference bridge circuit.
Alternatively, the microgateway may initiate a second VOIP call
from MG1 over the LAN or the dialup VOIP connection. Conference
bridge circuits are similar to two-way voice channels, except that
in these circuits, more than two channels converge at a single
point, which could be the conference bridge service circuit. Data
read from any one channel is copied to all other channels connected
to the conference bridge.
[0093] A voice channel is created to establish a third leg of
connection with the third party's equipment with the conference
bridge circuit. A connection is set up with the third party's
equipment, which includes transmitting an alert signal to the third
party equipment (e.g., a ring tone) and receiving an answer signal
from that third party equipment. These details are similar to tasks
that a central office switch performs when establishing a three-way
conference call.
[0094] After a third party is connected to the conference bridge
circuit, data from each party is copied to the other two parties,
thereby establishing a three-way communication. The same procedure
may be expanded to include a multiple party conference circuit.
[0095] Enhanced VOIP Architecture for a V.34 Modem
[0096] Internet Service Providers, such as America Online or Fry's
Internet, enable a customer operating a personal computer or other
similar device to connect with the Internet either directly or via
the ISP's network. Typically, these connections use a V.34 class of
modems. Where data connections are established--for example, where
facsimile and other connections are required--a data
compression/decompression scheme known as V.42 is typically
utilized. These features--V.34 for connection to the Internet, and
V.42 compression/decompression for data transfer--typically are not
optimal for delivering high quality VOIP telephone calls to a
user's CPE, such as a telephone handset. Accordingly, there is a
need to advance the art by enhancing a user's CPE.
[0097] Noting that the VOIP architecture uses a TCP/IP connection
and a Point-to-Point protocol connection between the personal
computer and ISP modems, the state of the art can be enhanced using
the following method. First, error correction is turned off.
Because VOIP is deterministic, based on a sampling or frame rate of
30 ms--if a packet is lost, this can be ignored instead of waiting
for it or adding any delay to correct the error. Second, data
compression, such as MNP, can be turned on to reduce the size of
text sent over a connection giving an apparent increase in transfer
speed. This is likely not the best solution for a VOIP call because
voice signal is already coded in an optimized way. Additionally,
data compression designed for data transfer must be turned off.
Third, the microgateway is connected at a specific predetermined
baud rate. It has been found that 21600 bits per second is suitable
for a low symbol rate without impacting the quality of service.
Because a VOIP call may need about 17 kb/s to connect, 21,600 b/s
is appropriate. These steps reduce the code size, MIPS, and
complexity while increasing the performance of the modem for VOIP
applications. This method could be used potentially on a variety of
modems, such as V.32 14.4 kbps modems and V.90, as well as with
ADSL systems especially when these devices operate in
voice-mode.
[0098] MG1 registers with server once turned on. After that a
periodic "heartbeat" packet is sent to the server to indicate that
the device is still on line and alive, ready for a call. If a call
is placed to another MG1, the server gets a packet from MG1
requesting the call to the other MG1. The server will look up a
destination unit, determine if the destination unit is online, then
signal the called and calling units. Once done, the calling and
called units connect directly over the Internet for peer-peer
communications. The server is signaled once the call is terminated
and both MG1's are ready for a call. If a call is placed to a PSTN
phone, MG1 connects to a H.323 gateway to setup the call.
[0099] VOIP Menu Display on Existing LCD Screens
[0100] A number of proprietary VOIP systems need to provide an
acceptable and uncomplicated user interface to a user that wishes
to program the VOIP system. For example, Aplio's proprietary system
requires a user to use the DTMF keypad of a POTS telephone to enter
data in order to program the system. Typically, a user is prompted
to enter a dial-up telephone number for an ISP, a user name and a
password. These data items are then repeated to the user via the
earpiece of the telephone handset or through a speaker embedded
within the system.
[0101] Another architecture could be to provide a keypad and an LCD
screen within the VOIP system itself. But this increases the
overall system cost. To overcome this issue, one may program the
VOIP system to use--instead of or in addition to the keypad of a
POTS telephone handset--an LCD screen that typically comes with a
telephone handset or with a Caller-ID box. Such boxes are marketed
by most of the telephone consumer electronic equipment
manufacturers such as CIDCO, Inc. of San Jose, Calif.
[0102] A telephony gateway, CPE Control protocol and a
telecommunication protocol engine and method have now been
illustrated. As described herein, the telecommunication protocol
engine and method results in significant reduction in on-chip
memory requirements and permits the use of otherwise memory limited
microprocessors. It will also be understood that aspects may be
embodied in other specific forms without departing from the scope
of the disclosure and that the examples and embodiments described
herein are in all respects illustrative and not restrictive. Those
skilled in the art of the present disclosure will recognize that
other embodiments using the concepts described herein are also
possible.
* * * * *