Abstract
This project involves creating a Home Calling Center installed into a
home PC and an independently operating box. This calling center will be connected to one or more phone lines
with Caller ID and three-way calling service installed. It will use the Caller ID information to
arbitrate received calls based on an internal or network defined database. The choices that the system would make may
be to forward to a different telephone number such as a cell phone or choose
from available mailboxes to save the message(ie. Junk Box, Important Box,
etc). This package will also facilitate
call screening through the announcement of voice calls and automatic call
blocking of unannounced or undesired numbers.
In addition, this system may have features such as voice dialing,
ability to handle multiple phone lines, ability to differentiate between a
voice and data calls and remote access.
Project Proposal Plan
Introduction
The Home Calling Center will ideally have a feature set which includes caller ID, call forwarding, and voice announcement of incoming callers. The systems actions will follow from a database containing preferred options for each number in the system. These options include BLOCK, FORWARD and VOICEMAIL. The BLOCK list will cause all calls originating from the sources contained within the list to ring infinitely. The FORWARD list will forward the calls that originate from the numbers in the list to a number specified by the user. And the VOICEMAIL list will allow the callers whose numbers are contained in the list to leave a message.
We would like to implement a hardware version of this product in order to art portability. The hardware version would consist of a single unit that will integrate the Home Calling Center.
The design of the project will include the consideration of optional features. Those features include toggling between states of HOME, WORK, or SLEEP, during which would cause the system to respond differently. Other optional features are remote access to software, and voice controlled dialing and menu navigation.
What Happens
When a Call Is Received
Our goal is to create a system with two different modes, mode A when the person is home and mode B when the person is away. In mode A, the person would hear the name of the caller through the voice announcement system and would in this case decide to take the call or let it go to voicemail. In mode B, a whole different process would be followed. This is where our database would be useful. Our home calling center would do a triage of the callers coming through. Depending on what list in the database a caller’s name appears, a specific action would be taken. The callers that are deemed very important would be forwarded to the person’s cell phone so that they may be able to reach him. Certain callers might be forwarded to a work number or any other number pre-chosen by the owner. In some cases, a message would be played. It will all depend on how urgent the call is considered to be. For example, a long time friend would just receive an usual message saying that the person is not home and to leave a message. Evidently, there will be a way to recognize unwanted calls such as telemarketers and their calls will just go in a trash box. The owner won’t even know that a telemarketer tried to call (he also has the option to visit that trash box or just delete everything). The final item would be for numbers that are not unwanted but are not on any list. Those calls would go to the answering machine as usual. The owner of such a system can in fact scan his messages and listen to the ones considered important.
When a call is received, the system waits for one ring. Then it collects the Caller ID (CID) information from the line including the telephone number of the caller. It uses the telephone number obtained as an index into the database. If it finds the number, it proceeds to follow the actins specified in the record found. These options may include voice announcement, forwarding to an alternate number, forwarding to one of the available mailboxes, or blocking. If the number is not found in the database, a check is performed to try to determine if the call is a sales call. If the call is a sales call it is dropped. If the call is not a sales call, it is forwarded to a default mailbox.
Extracting
Information From A Phone Line
The Caller ID (CID) information is sent serially at a rate of 1200 bits per second using continuous-phase binary frequency shift keying for modulation. The two frequencies used to represent the binary states are 1200 Hz for the Mark (logic 1) and 2200 Hz for the Space (logic 0). The data is sent asynchronously between the first and second ring at a signal level of -13.5 dBm.
The format of the CID information in the US is based on the Bellcore standard. Following a minimum of 500 ms after the end of the first ring, the sequence of transmission begins with a Channel Seizure. The Channel Seizure is a string of 300 continuous bits (250 ms) of alternating "0"s and "1"s. This string starts with a "0" and ends with a "1". A Mark Signal of 180 mark bits (150 ms) is sent immediately following the Channel Seizure Signal. The purpose of the Channel Seizure Signal and the Mark Signal is to prepare the data receiver in the Customer Premise Equipment (CPE) for the reception of the actual CID message.
Once the Channel Seizure and Mark Signals have been sent the CID information is then transmitted starting with the Least Significant Bit (LSB) of the most significant character. Each character in the message consists of 8 bits. For displayable characters these bits represent a code defined by the American Standard Code for Information Interchange. When transmitted the character's 8 bits are preceded by a start bit (space) and followed by a stop bit (mark) giving a total of 10 bits sent for each character. The CID information is followed by a checksum for error detection. Figure 1 shows a visual layout depicting the association of the 1st Ring, Channel Seizure Signal, Mark Signal, Caller ID Information, Checksum, and the 2nd Ring.
Figure 1 – Call Flow Chart
The Home Calling Center will use MDMF (Multiple Data Message Format), which displays CID information including the date, time, number and name. The fields that are sent along with their ASCII representation are shown below:
Character Decimal ASCII Actual
Description Value Value Bits (LSB)
-------------------------- ------- ----- ---------------
Message Type (MDMF) 128 1 0 0 0 0 0 0 0
Message Length (33) 33 0 0 1 0 0 0 0 1
Parameter Type (Date/Time) 1 0 0 0 0 0 0 0 1
Parameter Length (8) 8 0 0 0 0 1 0 0 0
Month (November) 49 1 0 0 1 1 0 0 0 1
49 1 0 0 1 1 0 0 0 1
Day (28) 50 2 0 0 1 1 0 0 1 0
56 8 0 0 1 1 1 0 0 0
Hour (3pm) 49 1 0 0 1 1 0 0 0 1
53 5 0 0 1 1 0 1 0 1
Minutes (43) 52 4 0 0 1 1 0 1 0 0
51 3 0 0 1 1 0 0 1 1
Parameter Type (Number) 2 0 0 0 0 0 0 1 0
Parameter Length (10) 10 0 0 0 0 1 0 1 0
Number (6062241359) 54 6 0 0 1 1 0 1 1 0
48 0 0 0 1 1 0 0 0 0
54 6 0 0 1 1 0 1 1 0
50 2 0 0 1 1 0 0 1 0
50 2 0 0 1 1 0 0 1 0
52 4 0 0 1 1 0 1 0 0
49 1 0 0 1 1 0 0 0 1
51 3 0 0 1 1 0 0 1 1
53 5 0 0 1 1 0 1 0 1
57 9 0 0 1 1 1 0 0 1
Parameter Type (Name) 7 0 0 0 0 0 1 1 1
Parameter Length (9) 9 0 0 0 0 1 0 0 1
Name (Joe Smith) 74 J 0 1 0 0 1 0 1 0
111 o 0 1 1 0 1 1 1 1
101 e 0 1 1 0 0 1 0 1
32 0 0 1 0 0 0 0 0
83 S 0 1 0 1 0 0 1 1
109 m 0 1 1 0 1 1 0 1
105 i 0 1 1 0 1 0 0 1
116 t 0 1 1 1 0 1 0 0
104 h 0 1 1 0 1 0 0 0
Checksum 88 0 1 0 1 1 0 0 0
Figure 2 –Caller ID Encoding
Upon receiving the CID message, the program will record the information from all the CID message fields in its call log and create a new entry within the database of callers. Then, it will use the telephone number as an index to the database and thus determine the next step it needs to take.
The Database
System
The database system is the heart of our project. It is used as the basis to determine almost all system actions. The objectives for a successful database are:
· Save space
· Provide quick and effective data access
· Provide multimedia support
· User-level access
· Concurrent access for call waiting
· Small Scale: At most 1000 records, prob. 500
· Windows Based
There should be two types of records: address book record and call record. The first type will be user defined and will be the basis for recognition of numbers. The second type of record will be created and stored every time a call comes in allowing for the user to browse through the last 100 or so calls. The format for the records are as follows:
Telephone Record:
· CallerName: String (20 char max)
· Telephone: Number (this is the database index)
· VoiceTag: String (optional, corresponds to filename where voice tag can be located)
· Action(s): String (Specifies name and parameters of actions to be taken for this number)
· Note: text (64 char max)
Call Record:
· Telephone Number: Number
· Date/Time: Number
In order to save costs, we expect to have a limited capacity. The maximum number of telephone records we expect to have is 500-1000, and the maximum number of call records we expect to have is 100. We expect this should provide for several days of storage.
We would like to include other options in the database if time permits, these potions include:
· Area code location matching
· Option to save entire database and move or append to a different database or a different system. This feature could be useful in the event of upgrades or damaged units.
We expect to have minimal security measures on our system. The measure we are considering are password protection and simple data encryption.
We considered the following API’s to create our database system:
- JDBC(Java Database Connectivity)
- ODBC(MS Open DataBaseConnectivity)
- Visual Basic
- Custom-made package
We decided against creating a custom-made package because, currently available market packages include querying, security, Concurrent Access, Established Structured Way to do things, Crash Recovery, New features can be easily added. These would take an incredible amount of effort to implement from scratch and the implementation would not be as comprehensive as the readily available standard APIs. Also, if later on we needed to add more functionality to our database we could easily do so using these packages.
We decided against Visual Basic as the language that interacts with the DBMS because we don’t want to deal with too many languages and Visual Basic is definitely not our language of choice for processing caller ID data or any of the other functions our program will be performing.
We are considering JDBC because it is a java based connectivity because it is easy to implement, it is easy to make a GUI for the database system, it is portable across platforms, it is portable and readily distributed free of charge by Sun Microsystems, Inc for use with the J2SE java package.
We are considering ODBC because it is C-based and may allow us to deal with the operating system and any hardware components quite easily. The C-language is slightly less friendly than others for the purposes of GUI, however, so if we decide to implement this choice we may have to use a different language for the GUI.
For the DBMS, we chose to use an SQL DBMS product with SQL-92 or SQL99, as these protocols are supported by both JDBC and ODBC.
Speech
Recognition
We intend to add speech recognition to our
project as a chief optional feature. It
would allow for full menu navigation and system management through a voice
interface. Speech recognition, or
speech-to-text, involves capturing and digitizing the sound waves, converting
them to basic language units or phonemes, constructing words from phonemes, and
contextually analyzing the words to ensure correct spelling for words that
sound alike (such as write and right). The figure below illustrates this
high-level description of the process.
Figure 3 - Speech recognition process flow
Recognizers-also referred to as speech recognition engines- are the
software drivers that convert the acoustical signal to a digital signal and
deliver recognized speech as text to your application. Most recognizers support
continuous speech, meaning you can speak naturally into a microphone at the
speed of most conversations. Isolated or discrete speech recognizers require
the user to pause after each word, and are currently being replaced by
continuous speech engines.
Continuous speech recognition engines currently support two modes of
speech recognition:
·
Dictation, in
which the user enters data by reading directly to the computer.
·
Command and
control, in which the user initiates actions by speaking commands or asking
questions.
Dictation mode allows users to dictate memos, letters, and e-mail messages, as well as to enter data using a speech recognition dictation engine. Command and control mode offers developers the easiest implementation of a speech interface in an existing application.
Speech recognition technology enables developers to include the following features in their applications:
·
Hands-free
computing as an alternative to the keyboard, or to allow the application to be
used in environments where a keyboard is impractical (e.g., small mobile
devices, AutoPCs, or in mobile phones).
·
Voice responses
to message boxes and wizard screens can easily be designed into an application.
·
Streamlined
access to application controls and large lists enables a user to speak any one
item from a list or any command from a potentially huge set of commands without
having to navigate through several dialog boxes or cascading menus.
·
Speech-activated
macros let a user speak a natural word or phrase rather than use the keyboard
or a command to activate a macro.
· Situational dialogs are possible between the user and the computer in which the computer asks the user, "What do you want to do?" and branches according to the reply. For example, the user might reply, "I want to call Stevens Student Service Center." The computer analyzes the reply, clarifies any ambiguous words ("Did you say Stevens Student Service Center?"), and based on the user response it will dial the number.
Speech Synthesis
Speech Synthesis, or text-to-speech, is the
process of converting text into spoken language. This involves breaking down
the words into phonemes; analyzing for special handling of text such as
numbers, currency amounts, inflection, and punctuation; and generating the
digital audio for playback. There are additional functions that the synthesizer
performs, but Figure 2 below illustrates this high-level description of the
process.
Figure 4 - Text-to-speech process flow
Software drivers called synthesizers, or
text-to-speech voices, perform speech synthesis, handling the complexity of
converting text and generating spoken language. It is easy to understand, the
voice produced by synthesis technology tends to sound less human than a voice
reproduced by a digital recording.
Since our main concentration is call
forwarding and creating a data base system, we would have to purchase the
Speech Synthesis and Speech Recognition software for the project. The software will be installed in the
computer to access the PC applications as well as mobile applications. The features that we intend to include in
our project using these technologies are:
1.
Voice dialing
2.
Voice
announcement
3.
Command and
Control (i.e. Yes/No response)
Once the software is installed, the user can
set all of the features in the system.
System Requirements:
Processor: Pentium II, 400 mgh
Ram: 128 MB or better
Sound Card: 32 MB or better
Modem: 56K or other
Hardware Components
As previously mentioned, a stand-alone hardware component will be designed to aid in both the portability and simplicity of the Home Calling Center. Although our final design calls for an ideal partnership between PC and hardware, it only makes sense to design a fully-functional box not unlike many of the Caller ID units for sale on the market today. Once the conceptual design and understanding of a completely independent unit is reached, a true interface between PC and hardware will begin to emerge. Finally, after our detailed cost analysis is added into the equation, we will have all the necessary tools to decide upon which components should stay in the box as opposed to those items better suited for the PC/software. That being said, not all of the hardware discussed below will be housed under the roof of our box, but everything has its place in the puzzle and nothing should be neglected.
The hardware skeleton can take on one of two primary forms depending upon our choice of CID message delivery. On-hook delivery entails transmitting information between the first and second rings of the incoming call. Simple and cost-effective analog solutions exist for On-Hook message delivery. Off-hook delivery (also known as Caller Identification with Call Waiting – CIDCW) complicates the process of data transmission/reception. Off-Hook FSK data may arrive at any time a call waiting may occur (not just between the first and second rings), and a special CAS (Consumer Premise Equipment Alerting Signal) tone, requiring acknowledgement, is also transmitted. Analog solutions to Off-Hook delivery are not as cost-effective nor are they as efficient as the corresponding DSP solution we are about to present. The use of DSP facilitates the detection of the special CAS tone, and it also allows for future software upgrades – making our hardware box adaptive in nature. For these reasons, we have chosen to design a box allowing for Off-Hook delivery. The typical component functions of our DSP chip are shown below:
Figure 5 –DSP Component Functions
Referring to above diagram: The chip will first decide the mode of delivery (On/Off Hook). When nobody is on the line, the simple On-Hook delivery scheme is followed, and all CAS/ACK blocks are bypassed. The band-pass filter removes all out-of-range frequencies (noise), and the resulting signal is sent to the demodulator which transforms the analog information into binary digits. This data is finally comprehended by the SDMF/MDMF data recovery block, and sent to the display.
If someone is using the line when a call comes in, the chip decides to implement an
Off-Hook solution. This requires the use of every block function shown above. The process treats the FSK data in the same manner as the On-Hook solution described above. The complexity however, arises in transmitting the CAS alert tone, along with the transmission of acknowledgement from the caller being interrupted. The extra CAS, ACK, and timer blocks exist for the sole purpose of managing this “extra” Off-Hook information.
Finally, we show
our tentative, independent, hardware box: 
Figure 6 –Tentative Hardware
Box
This diagram references a specific model of DSP chip (Z893XX), although our decision concerning which DSP chip best suits our needs is still to be decided. Regardless, all of the functions specified in the diagram previous to the above are performed and reside within the DSP /Logic block of the system view shown here. The “Phone” block would be an interface that
protects the CID circuit from the line (the high-voltage, ring signal can be damaging). The CODEC is nothing more than the analog front end of the DSP, receiving and transmitting serial data. The “Ring” block simply sends a digital signal to the DSP when a call is coming in. Finally, our box is obviously connected to the outside world via the phone jacks labeled RJ11.
Having desribed the major hardware components and their functionality, the remaining task is to decide which (if any) blocks to omit from our macroscopic, system diagram. For instance, there is a good chance that the LCD display will be replaced by a GUI interface on the partner PC. We are currently in the process of locating a ready-made evaluation board consisting of an interconnected majority of our necessary components. We would also wish to find a board consistent with today’s firmware capable modems. Firmware is a portion of hardware that can be electronically reprogrammed with software. Having this “flash ROM” hardware would likely facilitate the task of efficient PC-hardware communication.
Conclusion
We have proposed a design and implementation of a Home Calling Center, which incorporates existing caller ID technology with our own software and hardware packages. Potential Consumers would find our Home Calling Center to be favorable over standard caller id units because it has more features, and it is less expensive than other similar models already on the market. For these reason it will be a successful product and business investment.
Once again the features our Home Calling Center would include are caller ID, call forwarding, and voice announcements of incoming calls. The call forwarding would use DBMS to decide whether to forward the call, let it keep ringing infinitely, or drop the call to a voicemail. The voice announcements of incoming calls will use the current existing caller ID technology (CID) to get the caller’s name and then speech synthesis to announce the call. Many other optional features are being explored that will be added if time and costs permit.
As a software package only our design could be a legit product, but since not everyone has access to a pc all the time we decided we should also make a mobile version based on our software package. This in effect makes our design not one but two separate marketable products. If we can manage to develop most or all of the software on our own the costs of this product could be minimized to small packaging and marketing costs. While the mobile version of the product would be more expensive since it consists of a hardware and software package makes our product a viable option for many more customers.
