Call agents and systems and methods for providing emergency...

Telephonic communications – Emergency or alarm communications

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C379S090010, C379S201010, C725S106000

Reexamination Certificate

active

06466651

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to telephony and more particularly, to telephony over heterogeneous networks such as cable systems.
BACKGROUND OF THE INVENTION
Recently, great interest has been shown in the area of cable telephony. With the recent introduction of cable modems, cable operators have shown great interest in technology that will allow them to provide telephone services along with television and data services. If successful, such operators could offer customers (users) one data pipe that will handle data, video and voice. Investigation of the possibilities of cable telephony has begun, with much of the work in this area being performed by Cable Television Laboratories, Inc. (CableLabs). This work by CableLabs has resulted in a proposed specification (PacketCable) for Internet based voice and video products over cable systems. PacketCable has focused on Internet Protocol (IP) based telephony which interfaces with the existing Public Switch Telephone Network (PSTN) via conventional Signaling System 7 (SS7) based gateways. While the IP based telephony approach may be very flexible, it is a new and immature technology. It may take time to develop the rich set of telephony features that are currently offered by Class 5 telephony switches.
FIG. 1
illustrates the IP telephony architecture generally corresponding to that proposed by PacketCable. In the PacketCable 1.0 architecture, calls are typically controlled by a central Call Agent (CA)
170
. The Media Terminal Adapter (MTA)
110
uses a Data Over Cable Service Interface Specification (DOCSIS) Cable Modem
120
to communicate with the CA
170
over the cable network
130
and the IP network
150
through the Cable Modem Termination System (CMTS)
140
. While illustrated as two separate blocks in
FIG. 1
, the MTA
110
and the cable modem (CM)
120
may be a single device. Thus, the MTA
110
and the CM
120
may be a single cable modem with a telephony application which controls a standard telephone set
100
.
The MTA
110
is typically controlled by the CA
170
using a protocol known as Network based Call Signaling (NCS) which has been defined by PacketCable. The Cable Telephony Gateway (CTG)
160
interfaces the cable plant to the PSTN
180
using SS7. Voice is digitized and carried as IP packets between the MTA
110
and CTG
160
. The MTA
110
converts between analog voice and IP packetized voice while the CTG
160
converts between IP packetized voice and standard 64 kbps PCM for the PSTN.
When the MTA
110
powers up, it typically communicates with the CA
170
which instructs the MTA
110
to look for an off-hook condition. In a typical outbound call, the user picks up the phone
100
connected to the MTA
110
, or goes “off-hook.” The MTA
110
sends a NOTIFY message to the CA
170
to indicate the off-hook condition. If capacity is available on the cable system, the CA
170
typically instructs the MTA
110
to provide a dial tone and collect dialed digits. When dialing is complete, the MTA
110
sends the dialed digits to the CA
170
via the NOTIFY command. The CA
170
generally verifies that the user is allowed to place the call and then notifies the CTG
160
of the number the caller wishes to dial. The CTG
160
communicates with the PSTN
180
using SS
7
which is a message based protocol. That is, the CTG
160
typically tells the PSTN
180
the desired number to dial in a digital message. If the PSTN
180
accepts the call, the CA
170
generally sets up an IP connection between the MTA
110
and the CTG
160
. Voice is carried in data packets over the IP network and may be sent as continuous Pulse Code Modulation (PCM) data between the CTG
160
and PSTN
180
. If the caller has the feature Caller ID with call waiting and someone else attempts to call the original caller, the CTG
160
receives a SS7 message from the PSTN
180
that indicates an incoming call including the caller's ID. The CTG
160
notifies the CA
170
which then directs the MTA
110
to signal to the original caller that a call is incoming and to display the caller ID.
As is seen from the above example, in the PacketCable type system, the CA
170
generally controls all aspects of the call. The MTA
170
follows the instructions provided by the CA
170
. Furthermore, the use of SS7 signaling to interface to the PSTN
180
provides call information in a digital message format that the CA
170
can typically easily interpret to provide instructions to the MTA
110
.
While the PacketCable type system may provide a mechanism for providing basic telephony functions over a cable plant, some cable system operators may be unwilling to wait for the IP telephony technology to evolve and mature. These operators may have access to Class 5 switches, and may want to leverage this investment to deploy mature cable telephony as soon as possible. Therefore, a hybrid architecture has emerged which uses the Class 5 switch to control phone calls while the cable plant is used as the “last mile” connection to customers. However, merging cable telephony with the existing Class 5 switches is typically not straight forward because the two approaches have very different paradigms.
Typically, standard analog phone lines are connected directly to a Class 5 switch, so that the switch controls all aspects of the call. The switch detects off-hook, provides a dial tone and or ringing and handles advanced features like call waiting or caller ID. The switch typically controls the phone using in-band signaling such as dial tone and dual tone multi-frequency (DTMF) and electric currents and voltages to signal on-hook and off-hook as well as power ringing. As analog lines are generally limited to approximately 3 miles, remote data terminals (RDT) may be used to expand the reach of the switch. Such a system is illustrated in FIG.
2
.
As seen in
FIG. 2
, the RDT
210
attaches to the analog telephones
200
and
200
′ and communicates with the Class 5 switch
220
, and, therefore, the PSTN
230
, via a T1 or higher order digital link. The T1 can transfer in-band signals like DTMF, because these signals are typically sampled and pulse code modulation (PCM) encoded just like voice. However, the T1 generally cannot directly include the currents and voltages needed for hook detection and ringing. Therefore, ABCD signaling is typically used to convey this information. ABCD bits are part of the Enhanced Super Frame format used on T1s. Low order bits are “robbed” from the PCM stream to convey the extra ABCD information. The RDT
210
may convert ABCD bits to voltages and currents and vice versa. The RDT
210
is generally a slave to the switch, notifying the switch of events on the analog line or responding to commands from the switch, such as power ringing.
Initial attempts to merge the Class 5 switch and cable telephony produced the architecture illustrated in FIG.
3
. In this approach the RDT is replaced by the Cable Telephony Gateway (CTG)
300
and the analog telephone lines are replaced by an IP network
150
and a cable plant
130
,
140
of a cable system. The CA
310
and switch
220
both try to control the call. The switch
220
generally thinks it is talking to a regular RDT and it attempts to control the call using in-band signaling and ABCD bits. The CTG
300
does not receive formatted SS7 messages as in the PacketCable system described above, so it typically must interpret the in-band signaling and ABCD bits and convert them to NCS messages for the CA
310
. The CA
310
then may attempt to control the MTA
110
. This approach may fail, however, because of the tight timing requirements of the switch
220
. The latency added by interpreting in-band signals and coordinating with the CA
310
may cause many Custom Local Area Signaling Services (CLASS) features, such as Caller ID and Call Waiting, to fail.
One particular challenge for cable telephony systems using in-band control architectures, such as those described above with reference to
FIG. 3
, is supporting delivery of emergency call services. In particular, such sy

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Call agents and systems and methods for providing emergency... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Call agents and systems and methods for providing emergency..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Call agents and systems and methods for providing emergency... will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2972383

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.