ARS ¿©·ÐÁ¶»ç ÀüÈ­ È«º¸(PDS) SmartDialer-ACS °Ô½ÃÆÇ/ÀÚ·á½Ç ȸ»ç ¼Ò°³
°Ô½ÃÆÇ/ÀÚ·á½Ç
1. ÀüÈ­È«º¸(PDS) °Ô½ÃÆÇ
2. ÀÚ·á½Ç
3. ¼±°Å°ü·Ã °Ô½ÃÆÇ
 
±â¼ú ¹®¼­
Caller ID Basics



Caller ID Basics
by Michael W. Slawson

Executive Summary

Caller ID (CID), or Calling Number Delivery (CND) as it is sometimes called, came about as an extension of Automatic Number Identification (ANI). ANI is a method that is used by telephone companies to identify the billing account for a toll call. Although ANI is not the service that provides the information for CID, it was the first to offer caller information to authorized parties. The CID service became possible with the implementation of Signaling System 7 (SS7).

The CID information is transmitted on the subscriber loop using frequency shift keyed (FSK) modem tones. These FSK modem tones are used to transmit the display message in American Standard Code for Information Interchange (ASCII) character code form. The transmission of the display message takes place between the first and second ring. The information sent includes the date, time, and calling number. The name associated with the calling number is sometimes included also. Since the time CID was first made available it has been expanded to offer CID on Call Waiting (CIDCW) as well. With CIDCW the call waiting tone is heard and the identification of the second call is seen.

The purpose of this paper is to gather information from multiple sources dealing with CID and to present that information in a manner such that the reader can gain a basic understanding of CID and its operation.

Introduction

Although several articles about Caller ID have been written, the most complete information and definitions are still contained within Bellcore specifications. By combining general information from some of these articles with the specifics from the Bellcore specifications this paper will give a better basic understanding of CID in one central source.

Caller ID is the identification of the originating subscriber line. Although Caller ID is the most common name for the service, a more appropriate name would be Calling Number Identification since it is the directory number of the originating line that is used as the identification. In cases where the name and the number are sent, the name that is used is that which is associated with the number in the directory listing. The telephone company has no way of knowing who the actual caller is.

The CID information is sent on the destination subscriber loop between the first and second ring by means of two modem tones. The information is transmitted serially in FSK mode using one of the tones to represent a logic 1 (mark) and the other to represent a logic 0 (space). Caller ID uses the same frequencies, modulation type, and data format as the Bell type 202 modems[1].

The message consists of a Channel Seizure string followed by a Mark string and then the caller information. The information is sent in one of two formats. The Single Data Message Format (SDMF) contains the date, time, and calling number. The Multiple Data Message Format (MDMF) contains the date, time, calling number, and the name associated with that number. Optionally, the number and name fields may contain data indicating that the information has been blocked by the caller or is unavailable.

Background

The method for sending and displaying the CID information during a silent interval between rings was invented by Carolyn A. Doughty. This invention was filed for a United States Patent on July 12, 1983. It was assigned patent number 4,582,956 on April 15, 1986 with AT&T Bell Laboratories (now Lucent Technologies Incorporated) listed as the assignee.[2]

Caller ID was first offered in New Jersey in 1987 by New Jersey Bell[3]. The telephone company was interested in trying to earn additional revenue from its investments in new high-speed network signaling systems[4]. These new systems use a separate call data circuit based on the SS7 standard to handle the setup, termination, supervisory signals, and other data concerning a call. This separate call data circuit can handle the processing of multiple calls very quickly and eliminates certain types of toll fraud[5].

Prior to SS7 telephone companies used ANI for call billing purposes. With only a few exceptions, the billing information about the caller was not sent beyond the central office that provided that caller's service. The exceptions to this were authorized parties such as 911 services, law enforcement agencies, and more recently 800 and 900 number subscribers. Even today, ANI is still used by these parties[5]. Since ANI is completely independent of CID it will deliver the originating number even when the originator has blocked their number for CID purposes.

With the installation of the new SS7 systems it became practical to forward the calling party's identification through the telephone network to the central office serving the called party. This aspect of SS7 is known as Calling Party Number Message (CPNM). The CPNM includes the calling party's telephone number, and whether or not the calling party wants their number blocked from being seen by the called party. Note that the CPNM is sent out on all telephone calls that are made, regardless of whether or not the calling party wants their number blocked[5].

A major issue that came up with the offering of CID was that of privacy. In several states the implementation of CID was slowed by privacy advocate groups. These groups claimed that CID was an invasion of privacy. In April of 1994, the Federal Communications Commission (FCC) issued a ruling that established a national standard for CID and the delivery of the caller's number into the switched network. Local and long distance telephone companies that were equipped to do so had to exchange CPNMs. Along with this, the telephone companies had to offer blocking on a per call basis so that the caller could block their number from being delivered to the called party[4]. The CPNM is still delivered to the final central office serving the end subscriber, but the number is then blocked and the CID message marked as private.

Specifics

Caller ID, as it is most commonly called, is a term that encompasses more than one type of caller identification. Calling Number Delivery refers to the most basic type of CID. It is delivered in SDMF and includes the date, time, and calling number. Calling Name Delivery (CNAM) is an enhancement of Calling Number Delivery that adds the calling name and is sent in MDMF.

Bellcore has stated that a possible future objective may be to phase out the SDMF and use only the MDMF. In the event that SDMF is phased out, the name field in a MDMF message would be left out for customers who subscribe to number delivery only[6].

The 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 level is measured at the central office across a 900 ohm test termination[7].

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[7].

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. This is true for both SDMF and MDMF[6]. 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[7]. 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 - Sequence Layout and Timing


The checksum word is a twos complement of the modulo 256 sum of each bit in the other words of the message. The Channel Seizure and Mark Signals are not included in this checksum. When the message is received by the CPE it checks for errors by taking the received checksum word and adding the modulo 256 sum of all of the other words received in the message. The addition done by the CPE does not include the Channel Seizure and Mark Signals, nor does it include the received checksum word. The result of this addition should be zero to indicate that no errors have been detected[8].

Figure 2 shows a CID message in SDMF. For ease in describing the process of determining the checksum, the decimal values will be used for the calculations.


Character             Decimal   ASCII  Actual
Description           Value     Value  Bits      (LSB)
-------------------   -------   -----  ---------------
Message Type (SDMF)       4            0 0 0 0 0 1 0 0
Message Length (9)       18            0 0 0 1 0 0 1 0
Month (December)         49       1    0 0 1 1 0 0 0 1
                         50       2    0 0 1 1 0 0 1 0
Day (25)                 50       2    0 0 1 1 0 0 1 0
                         53       5    0 0 1 1 0 1 0 1
Hour (3pm)               49       1    0 0 1 1 0 0 0 1
                         53       5    0 0 1 1 0 1 0 1
Minutes (30)             51       3    0 0 1 1 0 0 1 1
                         48       0    0 0 1 1 0 0 0 0
Number (6061234567)      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
                         49       1    0 0 1 1 0 0 0 1
                         50       2    0 0 1 1 0 0 1 0
                         51       3    0 0 1 1 0 0 1 1
                         52       4    0 0 1 1 0 1 0 0
                         53       5    0 0 1 1 0 1 0 1
                         54       6    0 0 1 1 0 1 1 0
                         55       7    0 0 1 1 0 1 1 1
Checksum                 79            0 1 0 0 1 1 1 1
Figure 2 - A Caller ID message in SDMF

The first step is to add up the values of all of the fields (not including the checksum). In this example the total would be 945. This total is then divided by 256. The quotient is discarded and the remainder (177) is the modulo 256 sum. The binary equivalent of 177 is 10110001. To get the twos compliment start with the ones compliment (01001110), which is obtained by inverting each bit, and add 1. The twos compliment of a binary 10110001 is 01001111 (decimal 79). This is the checksum that is sent at the end of the CID information. When the CPE receives the CID message it also does a modulo 256 sum of the fields, however it does not do a twos complement. If the twos complement of the modulo 256 sum (01001111) is added to just the modulo 256 sum (10110001) the result will be zero.

If the result is not zero then the message is discarded. It is important to note that there is no error correction in this method. Even if the CPE were to notify the central office of errors, the central office will not retransmit the information. If an error is detected, the CPE receiving the message should display an error message or nothing at all[8]. Although Bellcore SR-TSV-002476 recommends that the CPE display an error message if erroneous data is received, most CPE manufacturers have elected to just ignore the errored message.

The content of the CID message itself depends on whether it is in SDMF or MDMF. A message in SDMF includes a Message Type word, a Message Length word, and the actual Message words. A message in MDMF also includes a Message Type word, a Message Length word, and the actual Message words, but additionally includes Parameter Type and Parameter Length words. There are certain points within these messages where up to 10 Mark bits may be inserted to allow for equipment delays in the central office[7]. These Stuffed Mark bits are generally not necessary.

The Message Type word defines whether the message is in SDMF or MDMF. It will be a binary 00000100 (decimal 4) for SDMF or a binary 10000000 (decimal 128) for MDMF. The Message Length will include the number of characters in the message. This length does not include the checksum at the end of the message. For SDMF the minimum length will be 9 characters. The minimum length for MDMF will depend on whether the customer has subscribed to CNAM service as well as CND. In the case of CND only the minimum length will be 13 characters. If the customer also has CNAM then the minimum will be 16 characters. In all three of the minimums mentioned there will be no actual number or name delivered. The field will be marked either "O" (Out of area) or "P" (Private)[6].

Figure 3 shows an example of a minimum message layout for SDMF. The number will not be delivered because it has been blocked by the calling party. The CPE will receive the date, time, and a "P" to indicate that the caller's identification has been blocked at the caller's request.


Character             Decimal   ASCII   Actual
Description           Value     Value   Bits      (LSB)
-------------------   -------   -----   ---------------
Message Type (SDMF)       4             0 0 0 0 0 1 0 0
Message Length (9)        9             0 0 0 0 1 0 0 1
Month (December)         49       1     0 0 1 1 0 0 0 1
                         50       2     0 0 1 1 0 0 1 0
Day (25)                 50       2     0 0 1 1 0 0 1 0
                         53       5     0 0 1 1 0 1 0 1
Hour (3pm)               49       1     0 0 1 1 0 0 0 1
                         53       5     0 0 1 1 0 1 0 1
Minutes (30)             51       3     0 0 1 1 0 0 1 1
                         48       0     0 0 1 1 0 0 0 0
Private                  80       P     0 1 0 1 0 0 0 0
Checksum                 16             0 0 0 1 0 0 0 0
Figure 3 - A SDMF minimum message layout

Figure 4 shows an example of a message in MDMF that contains both a number and a name.


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 4 - A CID message in MDMF

In Figure 4, if the number and name had not been included then the parameter types for those fields would be different. These alternate parameter types are used to signify that the data contained in that parameter is the reason for its absence. The parameter type for the number section would have been a binary 00000100 (decimal 4) and the parameter type for the name section would have been a binary 00001000 (decimal 8). When the parameter type signifies that the data contained is the reason for that fields absence, the parameter length is always a binary 00000001 (decimal 1). If the reason for absence is that the calling party does not want their number/name displayed then the parameter data would be a binary 01010000 (ASCII "P") for Private. If the reason for absence is that the information is just not available then the parameter data would be a binary 01001111 (ASCII "O") for Out of area[9]. The number/name may not be available if the calling party is not served by a central office capable of relaying the information on through the network.

Caller ID On Call Waiting

In carrying CID a step further and combining it with Call Waiting, a service commonly called Caller ID on Call Waiting has been developed. This feature is also sometimes called Calling Identity Delivery on Call Waiting. With CIDCW the identification of the party calling can now be seen without putting the current call on hold. CIDCW is done the same way as CID with only a few exceptions. One of those exceptions is that CIDCW only uses MDMF so the message type will always be a binary 10000000 (decimal 128).

Since CIDCW will only take place if a call is already in progress there will never be a ring signal preceding the message. The channel seizure signal is not used with CIDCW either. The central office gets the CPE's attention by sending it a CPE Alerting Signal (CAS), a two-tone signal described later. If the customer's equipment is ready to receive the CID information, it responds to the CAS by sending the central office an acknowledgment (ACK) signal. Note that the CPE will only respond to the CAS signal if it is the only extension that is off-hook[10]. If someone else is involved in the call on another extension, the CPE will not send an ACK signal to the central office because it cannot mute the second device. Most manufacturers detect whether an extension is off-hook by monitoring the line voltage. If the line voltage drops below a certain point then it is assumed that an extension is off-hook. This can lead to problems in situations where the CPE is placed on a very long loop. The long loop reduces the voltage at the CPE and causes its detector to continuously register an extension off-hook. At least one manufacturer is getting around this by designing the equipment to learn the line voltage that it should see during normal operation. This is done by taking the device off-hook two or three times so that it can register the normal off-hook voltage. If the voltage ever drops below this setting, it assumes that there is another extension off-hook. Once the central office sees the ACK signal it sends the FSK data[10].

When the CPE sees the CAS from the central office it mutes the telephone's handset before sending the ACK and receiving the FSK data. This act of muting serves two purposes.

First, it keeps the telephone user from hearing the FSK signal. But, more importantly it avoids interference from speech and other noises that would be picked up by the telephone's microphone. The muting only has to take place on the end receiving the FSK data since before sending the CAS, the central office momentarily removes audio to and from the far end of the current call. The audio is reconnected after the FSK data has been transmitted[8][10].

The sequence of events that displays the information about the caller begins when the central office temporarily removes the far end party of the current call and sends a Subscriber Alerting Signal (SAS) to the near end party. The SAS is a single frequency of 440 Hz that is applied for approximately 300 ms. This is the tone that is heard when a call is in progress and call waiting beeps to indicate a second call. The SAS tone is mainly for the user and is not required for the CPE to receive the CID information. The SAS tone is followed by a CAS to alert the CPE that it has CID information to send. The CAS is a dual tone signal combination of 2130 Hz and 2750 Hz that is 80 ms in length. Once the CPE hears the CAS it mutes the handset of the telephone and returns an ACK signal to the central office. This ACK signal has a nominal tone duration of 60 ms and is either a Dual-Tone Multifrequency (DTMF) "A" or a DTMF "D". The DTMF "D" is the most common ACK signal and it consists of the frequencies 941 Hz and 1633 Hz. A DTMF "A" consists of the frequencies 697 Hz and 1633 Hz. Once the central office receives the ACK signal it in turn sends the CID information[7][8][10]. The CPE un-mutes the handset as soon as it finishes receiving the FSK signal.

A problem that is sometimes experienced with CIDCW is Talkoff. Talkoff occurs when the CPE falsely detects a CAS. Speech can sometimes be interpreted by the CPE's detector as a CAS from the central office[8]. When talkoff occurs both parties will hear a brief interruption in the conversation and the party on the far end will hear the ACK signal that is sent to the central office by the CPE. When the handset is muted by a talkoff, the CPE will timeout and un-mute the handset after waiting a set period of time for an FSK signal[11]. Bellcore SR-3004 specifies that this timeout period should be no more than 501 ms from the end of the ACK signal. A CPE's detector will behave differently with different people because of the variations in each persons voice and speech patterns. Speech can also cause a valid CAS signal to not be recognized by the CPE. When this occurs, it is called a Talkdown.

The last difference between CID and CIDCW is that instead of being preceded by the 300 bits of Channel Seizure Signal and 180 bits of Mark Signal, as with standard CID, the Caller ID message for CIDCW is only preceded by 80 bits of Mark Signal[8]. CIDCW still uses the checksum just like CID.

Conclusion

Although CID can be very useful in screening calls, it is not limited to this application alone. For example, a number of business contact-manager software packages have made it possible to use CID to automatically bring up client information from a database and display it on the screen of a personal computer (PC) before the call is answered. Implementation of this requires a CID hardware device with a data connection to the PC. As time goes on we will see more and more uses for CID. Even though an "Out-of-Area" message may still seen occasionally, it will be less and less often as the remaining telephone offices which are not yet setup for CID install the necessary equipment.

Even as there are advances being made in the way Caller ID can be utilized, there are also advances being made in the customer premise equipment. Manufacturers are now coming out with units that allow multiple extensions to be off-hook and still receive CIDCW. Although the same manufacturer's equipment must generally be used on all extensions, this does allow more than one person to be on the same call and still see the identification of a waiting call. Even the small office key telephone systems are now offering CID and CIDCW capabilities so that caller information coming in on a line can be displayed at all stations associated with that line. Implementation does not always mean replacing a currently installed telephone system. Some manufacturers are offering upgrades to existing hardware by simply replacing specific printed wiring cards.


Glossary

ACK -- Acknowledgment
ANI -- Automatic Number Identification
ASCII -- American Standard Code for Information Interchange
BFSK -- Binary Frequency Shift Keying
CAS -- CPE Alerting Signal
CID -- Caller Identification or Caller ID
CIDCW -- Calling Identity Delivery on Call Waiting or Caller ID on Call Waiting
CNAM -- Calling Name Delivery
CND -- Calling Number Delivery
CPE -- Customer Premise Equipment
CPNM -- Calling Party Number Message
DTMF -- Dual-Tone Multifrequency
FCC -- Federal Communications Commission
FSK -- Frequency Shift Keying
ID -- Identification
LATA -- Local Access and Transport Area
LSB -- Least Significant Bit
LSSGR -- LATA Switching Systems Generic Requirements
MDMF -- Multiple Data Message Format
OSI -- Open Switch Interval
PC -- Personal Computer
SAS -- Subscriber Alerting Signal
SDMF -- Single Data Message Format
SPCS -- Stored Program Control Switching System
SS7 -- Signaling System 7

Bibliography

[1] CASE, Publication 918-5477, "T202T Modem Installation and Operation Instructions", Issue 18, August 1987

[2] Internet Web Page, http://www.uspto.gov/, United States Patent And Trademark Office

[3] Anonymous source at Lucent Technologies Incorporated, Telephone interview, 3 December 1996

[4] Wally Roberts, "Caller ID: The Telephone's Status Quo Is Gone" http://www.wallyroberts.com/phone/

[5] Wally Roberts, "Caller ID: The Technical 'A-B-Cs'" http://www.wallyroberts.com/phone/caller-id/ABCs/index.html

[6] Bellcore, TR-NWT-000031, "CLASS(SM) Feature: Calling Number Delivery", Issue 4, December 1992 (a module of LSSGR, FR-NWT-000064)

[7] Bellcore, TR-NWT-000030, "Voiceband Data Transmission Interface Generic Requirements", Issue 2, October 1992

[8] Bellcore, SR-TSV-002476, "Customer Premises Equipment Compatibility Considerations for the Voiceband Data Transmission Interface", Issue 1, December 1992

[9] Bellcore, TR-NWT-001188, "CLASS(SM) Feature: Calling Name Delivery Generic Requirements", Issue 1, December 1991 (a module of LSSGR, FR-NWT-000064)

[10] Bellcore, TR-NWT-000575, "CLASS(SM) Feature: Calling Identity Delivery on Call Waiting", Issue 1, October 1992 (a module of LSSGR, FR-NWT-000064)

[11] Bellcore, SR-3004, "Testing Guidlines for Analog Type 1, 2, and 3 CPE as Described in SR-INS-002726", Issue 2, January 1995