COCOT Experimenter's Resource Guide
by Dastar Com
Although the question "What is a COCOT?" is rarely asked anymore, interest in COCOTs has remained high due to the fact that so much is still unknown about them. They are different from normal payphones and thus garner more attention from the curious. When you call them they sometimes emit a carrier and afford many hackers the fantasy of eventually breaking their protocol and discovering the secrets which are locked inside.
In this article, I intend to explain not only the internal hardware and operation of a COCOT, but also the business side of owning and operating payphones: the operational maintenance requirements as well as revenue collection and what goes into it.
Since most of my experience with COCOTs to this point has been with Intellicall brand payphones, this article deals specifically with their configuration and operation. A large number of the COCOTs in operation around the country are Intellicall payphones and finding one shouldn't pose a problem for would-be experimenters. Plus, enough of the information is generic enough to be applied to other brands of COCOTs.
Beware the COCOT
Hopefully by now you know enough about COCOTs that you try to avoid using one at all costs (cost is the keyword here, because they have a notorious reputation of charging horrendous rates). A long time ago I came across a phone which charged $1.50 per 950 call! I called the phone's owner and bitched to him about this and ordered him to remedy the situation. He simply offered the location of alternate phones across the street to use. I later checked to see if the $1.50 charge was dropped; it hadn't been. That phone has since been removed. Good riddance. If you find a COCOT that isn't complying to the FCC regulations, call the FCC and complain. COCOT owners can face hefty fines for non-compliance. FCC regulations now require COCOTs to allow free access to 10xxx and 950 numbers.
COCOT rates are usually higher than standard Bell rates as the COCOT owners will charge the maximum of what FCC regulations allow. Why are they such a rip-off? There are a few reasons. Of course there are those payphone operators who are just plain (((greedy))) and don't care what they charge, but those operators are a small minority. As with any business, the major reason is operating expenses.
COCOT owners don't have the budget that the big RBOCs have. Its harder for them to turn a profit operating payphones due to the tighter regulations imposed on them and the stiff competition. Also, as evidenced by the many letters appearing in 2600 from disgruntled COCOT users, their equipment costs are extremely high. Each payphone can cost around $1,000 or higher and requires constant maintenance and servicing.
Let it be known that payphone operators make next to no profit on coin calls due to FCC tariffs. They make the real money in the surcharges they levy on collect and calling card calls.
Trickery and Deception
As revealed in previous articles, some COCOTs can be fooled into returning you their unrestricted dial tone.
This is not the case, however, with Intellicalls. Rumor has it they were field tested in prisons, so the Intellicall engineers have probably been exposed to every trick in the book. Intellicalls have very advanced anti-fraud mechanisms. Their main defense against surrendering their dial tone is by detecting it outright. As soon as dial tone is detected (where it shouldn't be detected) the phone cuts off the handset (detection time is very brief... about 50 milliseconds).
By now everyone knows about the 800 number trick to acquire an unrestricted dial tone: call an 800 number, wait for the called party to hang up and then, voilà, unrestricted dial tone. The reason this works (or at least used to as more and more COCOTs these days are using COPT lines as discussed later) is because 800 numbers do not return a "wink" signal when they disconnect. A wink is a momentary drop in the line loop current which signals the local CO equipment that the remote end has hung up. Intellicall payphones have wink detection options included in their software to protect against this well-known trick.
There is another way though. If you're patient, scan your local prefixes for a number which, when called, immediately returns a dial tone. If you can locate one of these then what you have found is a number that hangs up but does not return a wink. This is very valuable for COCOT scamming, as you can dial this number from a COCOT and then call anywhere using the unrestricted dial tone, all for a quarter!
Depending on the COCOT you'll sometimes even get your quarter back at the end of the call. A number like this usually resides in the 00XX or 99XX range of your local prefixes. However, in order for this number to work as desired, you must be calling it from an exchange that is not serviced by the switch which services the special "no-wink" number.
For example, if the "no-wink" number is located in (415)-567 which is serviced by switch SNFCCA19CG0 and you called it from (415)-566 which is serviced by switch SNFCCA14CG0 then you would be returned a dial tone without a wink signal. It would not work if you were calling from (415)-567 (i.e., being serviced by the same switch as the "no-wink" number) or if you were calling outside of the LATA which the "no-wink" number is located in.
Contrary to popular belief (at least, in the case of Intellicalls), the dial tone you first hear when you pick up the phone isn't synthesized, it's the actual line dial tone. As soon as you enter the first digit though, the real dial tone is cut off and the dialed digits are buffered. Before the number is actually dialed it is checked against internal area code and prefix tables (programmed by the payphone operator) and the rates for the call are computed (again from internal rate databases). If money has not yet been entered, the payphone prompts the user to insert the required amount.
The Guts
COCOTs aren't dubbed "intelligent payphones" for nothing.
COCOTs are basically computers, including upwards of 64k of RAM/ROM, speech synthesizers, 300 or 1200 baud modems, and a whole slew of other interesting circuits (tone decoders, frequency detectors, etc.).
Inside the payphone exists extensive local area code and prefix tables (NPA-NXX tables), plus rate and surcharge tables covering rates for anything from AT&T, Sprint, and MCI calling cards to Visa and Mastercards (on those phones which are configured to accept commercial credit cards). The phone uses its internal tables to determine what type of call you are making (Local, Intra-LATA, etc.) and calculate how much that call will cost.
If you've ever tried to dial a non-existent phone number from a COCOT you know that it won't allow it. It knows which exchanges are valid in your area code because it has them all programmed inside its database. Thus, any number dialed that is not valid according to the internal databases is rejected. As many of you may already know, any attempt to dial the local ANAC to learn the COCOT's phone number is usually thwarted, unless the number exists in a valid prefix (uncommon).
This can be easily overcome by simply dialing 0 for a local operator and requesting the number of the payphone. Since it is a public payphone, the operator usually complies and reads back the number.
However, dialing zero does not always guarantee you'll be routed to a local Bell operator. Sometimes you are connected to a subscribed operator service center which will not likely know what number you are calling from, but this is usually the exception rather than the norm.
Most COCOTs have at least a couple of speech files stored within their nigh-impenetrable barriers. Speech files are pre-recorded messages that prompt the caller to do certain things, such as enter a calling card number or say a name for collect calls. Speech files are not the synthesized voices you hear, such as the annoying "Thank you" after you make a call on Intellicalls. They are actual digitized human voices stored in the phone's memory, ideally to customize the phone to a certain operator's liking.
COCOTs can be programmed to perform a specific set of instructions (called "Outpulse Rules") to place a call depending on what the caller enters. For example, it can be programmed to accept the caller's destination number and calling card, then dial out to a validation service, send the calling card number for verification, wait for a reply and, based on whether the card is valid or not, either place the call or "splash" (forward) the caller to a live operator, an alternate long distance service, or a recording.
For Intellicalls a total of nine outpulse rules can be programmed for each phone, with 38 characters available for each rule. The payphone can be programmed to act as a stand-alone unit or to interface with various long distance companies or custom validation systems in order to place calls.
The outpulse rules are basically a sequence the phone will follow based on the signals received over the line. For example, the bong tone you hear when you use your calling card isn't there just to sound quaint. Its sole purpose is for automated call processing.
If a phone needs to place a call using AT&T, it can be programmed to dial the AT&T access number, listen for the bong, and then send the calling card and dialed number.
Remote Access
Many people have called a COCOT at one time or another and discovered interesting things. Some COCOTs play odd messages and series of Touch-Tones (Intellicalls) while some give a 300 or 1200 baud carrier outright.
The fact is, all COCOTs are accessible remotely. This is necessary primarily for reporting coin totals during money collection (as described above) but also to reload the phone's program and data when such a need arises. By now most of you have called a COCOT which will say "Thank you" in a computerized voice and then play four DTMF digits.
If you experimented around a little and pressed the right Touch-Tones you were given a 300 baud carrier. The excitement that rushed through your blood eventually dissipated however after many minutes spent trying to evoke some kind of response from the phone upon connecting to it with your computer.
Try as you might, you're probably never going to be able to hack your way into a COCOT.
Accessing Intellicall payphones first of all requires the I-NET software and hardware board. The I-NET software is a database program which allows the owner to maintain his payphones' file and keep track of revenue. It is virtually useless without the Intellicall I-NET board which is a proprietary communications card that plugs directly into a PC. It can be configured for either COM1 or COM2 and looks and acts basically like a modem. It has two RJ11 phone plugs in the back to accommodate a phone line, a 9-pin male serial connector to program a phone locally via direct serial link and an external speaker port.
Actually gaining access to a payphone also requires the payphone's serial number, which is used as a password to authenticate access. "Logging into" a payphone is all transparent to the user, as the payphone is dialed and logged into automatically by the I-NET software.
The four Touch-Tone digits you hear when you call an Intellicall are decoded by the I-NET board and used to determine the phone's firmware revision level. The I-NET board will then respond with a digit sequence of its own in order to evoke a carrier from the phone to begin the communications session.
Through experimentation, I have observed the following DTMF handshakes:
Example: I-NET dials phone, phone sends AB45, I-NET sends 9, phone emits carrier.
At this point, I can only speculate that after the I-NET software logs into the phone it sends a data handshake consisting of the phone's serial number and then executes any required data transfers.
All COCOTs come with some sort of network software package for performing remote data and program updates to the phones. The software is normally in operation on a dedicated PC 24-hours-a-day so that phones can call in as necessary to transmit money totals and reload their databases as needed.
During updates the phone is incapable of placing outgoing calls since it is using the phone line for its communications to the host system. On Intellicalls, the caller continuously hears "Please wait" through the earpiece until the modem transaction has completed.
Some COCOTs can be configured to call into the host system to report special conditions such as hardware errors for missing hardware (i.e., missing handset, missing card reader, etc.). They can even be configured to report in when someone leaves the handset off-hook!
Intellicalls can report special conditions either by uploading a message via modem or speaking a message using its voice synthesizer. For example, if it calls the special conditions number and receives a carrier it will attempt to connect to the remote system and then upload its error message. Otherwise, it will detect a human answer and "say" the message to the person answering the call.
Local Collection and Service Access
Some payphones, Intellicall's included, can be accessed locally from the keypad to perform simple service and collection tasks.
On Intellicalls, this is accomplished by picking up the handset and pressing the # key followed by a four-digit access code. The phone will then take the service technician through a series of voice prompts (or, in the case of LCD equipped phones, prompts on the LCD display) in order to perform different features, such as collecting the money in the phone and clearing the totals.
The default access codes for Intellicalls are #9999 for collection and #2001 for service.
However, these are usually changed as recommended by Intellicall, so a little hacking will probably be in order. If the defaults are still there, you lucked out severely.
Unfortunately, the service code is useless without the phone's upper housing key. Service access can only be activated after unlocking the upper housing. As soon as the lock is opened, the service code must be entered at the keypad or else the phone will dial out and report an unauthorized access.
Another feature sometimes present from the COCOT keypad is speed-dial: pressing the * and then a number 0-9 (or 00-99) on some COCOTs will speed-dial a pre-programmed number. Usually these numbers connect you to the payphone operator's business office or repair numbers. I have come across one strange COCOT that speed-dialed a fax number. Go figure.
Billing and Validation
Aside from coin revenues, payphone operators may also collect revenues from the collect and calling card call placed from their phones. This is accomplished by retrieving the call records generated by the payphones and sending them off to the phone company for collection.
Most private payphone operators do not have enough volume to deal directly with the LECs to bill and collect these revenues. This is where billing and collection clearing houses come in. These clearing houses (some examples being OAN, Resurgens, Integretel, and ZPDI) have direct billing agreements with most of the telephone companies (LECs) around the country (many of you may have seen these strange companies pop-up on your phone bill unexpectedly at one time or another).
The call records are sent to the clearing houses in the Bellcore Extended Message Interface (EMI) format. Each call record contains all the information required for the clearing house to route that particular phone charge to the proper LEC to then be placed on the customer's bill.
After the LEC collects the charge from the customer and takes a percentage for its billing and collection services, it forwards the balance back to the clearing house, which in turn takes a small percentage for its billing and collection services and then forwards the remaining balance to the payphone operator.
Each month the clearinghouses send out a list of all the LECs they have direct billing agreements with in the form of NPA-NXXs (area codes and prefixes). This is referred to as ONNET. Those prefixes which the clearing house cannot bill to (referred to as OFFNET) are simply restricted to calling on the payphones to prevent uncollectible revenues.
Payphone operators can further reduce uncollectible and fraudulent charges by subscribing to a validation service. The purpose of this service is to screen out undesirable billing numbers (i.e., canceled calling card numbers or third-party/collect call numbers which do not allow third-party/collect calls) either on a "live," call-by-call basis whereby the payphone calls into the validation service each time a calling card or third-party/collect call number is dialed or on a post validation basis, whereby numbers are collected for a certain period of time (say a week) and then validated all at once as a batch.
Those numbers which are found to be invalid are restricted from further calling from the payphone. Those with quick reflexes may have already realized that it is thus possible to get away with using an invalid calling card for an indefinite period of time before it is discovered and restricted on phones that are using post validation. You see, with post validation, the phone must assume that any calling card number you enter is valid until it can be validated later. So it will normally place a call with the fake number until it discovers that the card was, in fact, invalid.
This is becoming more and more rare these days as more payphone operators are opting for live validation.
Typical "Live" Validation Process
1.) Consumer dials collect call or enters calling card number.
2.) Payphone dials out to validation service (Intellicall phones can use Intellicall's VICS service as well as DTMF-based services).
3.) Service answers, payphone sends its ANI and billing number.
4.) Validation service accesses LIDS database to determine status of billing number.
5.) Validation service then notifies phone of number's status.
Intellicall offers its own validation system called Validation Interface Computer System (VICS). VICS differs from typical validation services in that it uses modem communications to perform the validation, rather than via DTMF.
The phone uses its internal modem to dial the VICS system at 300 baud. After a connect, the phone sends all the necessary billing information and VICS returns an appropriate reply (either valid or invalid). All this takes place in around 15 seconds.
Validation can be implemented by means other than via live, automated services. Some COCOT owners (less and less these days though) may opt to send all their collect or calling card calls through a costly Alternate Operator Service (AOS). This works by programming the payphone to dial an AOS access number whenever a patron initiates either a collect or calling card call whereby a live operator will handle the call from there. The AOS takes a portion of the revenues of each call processed by them, which obviously cuts down on the COCOT operator's profits.
Before live validation services became feasible, payphones would sometimes use what is referred to as "gray validation" to validate calling cards. Calling card numbers were verified by having the payphone dial itself (with the calling card entered by the phone patron) and then listening for a busy signal. If the calling card was good, the phone would get a busy signal since it was calling the same line it was dialing out on. This type of validation has been outlawed by the FCC because it was deemed the payphone was using the local LEC's lines to complete the call and earn revenue from it without compensating the LEC for the use of its line facilities.
How Numbers Are Validated
A question one might be asking at this point is just how are these numbers validated?
Every LEC in the country maintains what is called a Line Information DataBase (or LIDB). Each LEC is responsible for maintaining its own LIBC and keeping it current with all the valid phone numbers and calling cards that are available under that LEC.
Furthermore, the LIDB contains information specific to each billing number, such as whether that customer allows collect or third-party calls, and it even keeps tabs on calling card usage: how many times the card was used for how many minutes, the number of hack attempts, etc.
The database also contains fraud thresholds specific to each calling card and can automatically cancel a calling card if its usage surpasses a preset threshold (this threshold can be determined by the owner if desired).
The bottom line is, if it's not already hard to abuse calling cards today, it sure will be in the very near future. Of course, you'll still be able to scam a few free calls, but the intelligence of the networks will catch on and block the cards sooner.
Currently there are seven major LIDB hubs (one for each RBOC) which are all interconnected via the SS7 network (a closed X.25 PSN). Access to the major LIDBs is limited to smaller LIDB hubs such as SNET. SNET is a gateway by which validation service providers can access the major RBOC LIDBs for billing number validation. SNET is also set up to perform credit card authorization via a gateway to all the major credit card databases (Visa, Mastercard, etc.).
SNET has a whole slew of replies it can give regarding a billing number, all in the form of a three-digit code. This code tells whether or not a calling card is valid, or whether a certain phone number accepts collect or third-party calls, or whether a number is a payphone (and if so, what kind - private payphone, public payphone, semi-private payphone, etc. There are many different payphone classifications).
Following is a description of validation messages specific to Southern New England Telephone's (SNET) validation service.
SNET used to be accessed through Telenet but is now only accessible via a dedicated X.25 data line connected directly to SNET's premises.
SNET Query Request
The Query Request Message is pretty unwieldy.
Most of the information contained in the packet is simply for transaction record-keeping purposes (such as the date, time, message sequence number, etc.).
The first part of the message (the part up to the semicolons) is referred to as the header and contains mainly message identification.
The DQ simply identifies this message as a request.
The next four characters collectively compose a hexadecimal value. When converted to binary, this value flags which fields will be present in the remainder of the message (see Table A).
The Message Type defines the type of message:
- 0200 = Request
- 0210 = Response
The Transaction Type is:
- 00 = Calling Card Queries
- 01 = Collect Call Screening
- 02 = Third-Party Billing
- 03 = Commercial Credit Card Queries
The Message Sequence Number is available for matching queries to their replies (i.e., a serial number).
The Data Indicator flags whether data items will follow in the Message Body (i.e., Account Number, PIN, etc.).
The Response message is the same as the Request message except that a three character Reply Code is included which is then interpreted to determine the validity of the billing number queried (see Table B for sample reply codes).
Example 1: Sample SNET Query Message
- DQ - Marks beginning of query.
- FE00 - The message field bit map (marks which fields are present in query).
- SNETUSER - The 8-character User ID.
- 0200 - The Message Type (Query).
- 01 - The Transaction Type (Collect Call).
- 123456 - The Message Sequence Number (the serial number of the query).
- 1 - The data indicator (a 1 means data is to follow, 0 means no data to follow).
- 951027 - The date of query (YYMMDD).
- 213400 - The time of query in 24-hour format (HHMMSS).
- ;; - The message separator (separates message portion of query from data portion).
- 80C0 - The data field bit map (marks which fields are present in query).
- 5167512600 - The billing number (PIN number will follow for calling cards).
- 6178909200 - The originating number (referred to as ANI).
- 5044433999 - The destination (called) number.
Example 2: Sample Transactions
The first sample transaction (Query #1) is a validation request for calling card number: 51675126009999
The reply code (Reply #1) was: 211 (Denied - Invalid PIN)
The second sample transaction (Query #2) is a request for a third-party collect call verification. The originating number is: 617-890-9200, the number being called is: 504-443-3999, and the number the call is to be billed to is: 516-751-2600
The reply code (Reply #2) was: 050 (Conditionally Approved - Verify Third-Party Call)
Which means the call must be verified with the billed party before the call will be placed. Another possible reply would be: 005 (Approved Third-Party Call - No Verification Required)
I'll leave it up to the reader to decode the reply fields as an exercise.
Table A: Header Field Bit Map Translation
Table B: Sample Reply Codes
Any code less than 100 is generally an approval code, and anything equal to or greater than 100 is a denial code. Codes in the 100 series mean there was error in the query (missing field, bad format, etc.).
Codes in the 200 series are denials for Billed Number Screenings (BNS) (i.e., calling card, collect, and third-party calls).
Codes in the 300 series are denials based on fraud control screening.
Codes in the 400 series are commercial credit card denials.
The Bells Fight Back
A new breed of payphone which is Red Box resistant seems to be popping up all over the place. These phones are similar to COCOTs in that they are somewhat intelligent. They can be dialed-up and polled like a COCOT for remote maintenance and other features.
Red Boxes are rendered ineffective as the payphone simply seems to ignore the external tones and keeps demanding money until either you hang up in disgust or the live operator comes on the line to tell you to either put some money in or give it up. I hope to present more information regarding these new payphones in a future article of this series.
COCOT Survival Tips
To avoid excessive calling card charges, dial 0 to get a local Bell operator and ask him/her to place the call for you.
This way, your card is billed by the Bell (with its normal rates) as opposed to the COCOT operator who will most likely tack on ridiculously high calling card surcharges to the total charge.
Miscellany
Most RBOCs now offer special COPT lines to payphone operators. These lines are tailored specifically for COCOTs in that they have inherent number blocking and, most importantly, will never return an unrestricted dial tone by way of dialing numbers which do not return a "wink" (such as 800 numbers). Local operators will automatically be able to recognize COCOTs utilizing COPT lines as just that.
Where Do I Go From Here?
Now you know there is more to COCOTs than is readily apparent.
They are pretty fascinating devices. If you'd like to learn more, I would suggest trashing a local COCOT operator to see what kind of interesting things they are throwing out. Most operators will post their address right on the phone itself, so that's a good place to find directions to your local neighborhood COCOT operator.
Also, try a little experimentation on the COCOT itself. Try to gain access to the CO line and clamp a butt-set on it. Make a few different types of calls and observe what you hear on the line. Punch in random digits on the keypad starting with the * or # keys. You may find some interesting things.
In the meantime, I'll be continuing my research into the mysterious ways of the COCOT and hope to present even more informative articles in future issues of 2600.
Until then, hack and be merry!
Glossary of Acronyms
Other Sources of Information
Intellicall Outpulse Rules
A This command instructs the payphone to dial its 10-digit phone number (ANI) via Touch-Tone B Set the DTMF code for invalid - this is the 2-digit DTMF code that the validation service will return to signal the phone that the billing number is invalid. See also Rule "O". C Instructs the phone to send the caller's calling card number, if one was entered, via DTMF. D Instructs the phone to send a card's expiration date (in the case of commercial credit cards). E This command waits for a card verify signal from the validation service. F Fail string start indicator - if a command fails for any reason, the portion of this outpulse rule following the "F" will be used to process the remainder of the call. I Instructs the phone to dial the caller's destination number directly independent of the way it was originally dialed. M Instructs the phone to send any miscellaneous information about the credit card entered. N Instructs the phone to dial the caller's number as it was entered by the caller. O Set the DTMF code for valid - this is the 2-digit DTMF code that the validation service will return to signal the phone that the billing number is valid. See also Rule "B". P Instructs the phone to pause for one second before call processing continues. Q Instructs the phone to dial the caller's destination number as a 0+ call, meaning that the number will be outpulsed as an operator assisted call. S# Instructs the payphone to dial a pre-programmed phone number from the speed-dial list (can only be either S6, S7, S8, or S9). T Instructs the payphone to wait for a 400 Hz tone before continuing. U Instructs the payphone to dial the number entered by the patron modified to 10 digits (i.e., if only 7-digits were entered, a local area code would he added to make the number 10-digits). V Instructs the payphone to use VICS for validation. W Instructs the payphone to wait for either 400 Hz or a steady dial tone. w Override timeout on next wait command - specify a timeout other than the default on the next wait command. X1 Instructs the payphone to dial the Alternate Carrier number (i.e., in order to place a call over an alternate long distance carrier). X2 Instructs the payphone to outpulse the Alternate Carrier access code. X# Instructs the payphone to dial a preset connect number (must be either X3, X4, X5, X6, or X7). * Instructs the payphone to dial a '*'. # Instructs the payphone to dial a '#'. ( Start of 0+ conditional string - if the number entered by the phone patron starts with a 0 (i.e., collect call), then process the commands enclosed in the parenthesis. ) End of 0+ conditional substring. [ Start of non-0+ conditional string - if the number entered by the caller does not start with a 0 (i.e., a direct-dialed call), then process the commands enclosed in the brackets. ] End of non-0+ (direct-dialed) conditional substring. { Start of credit card conditional string - if a credit card number is available then begin processing the commands enclosed within the braces. } End of credit card conditional string. < Start of no credit card conditional string - if no credit card number is available then begin processing the commands enclosed within the brackets. > End of no credit card conditional string. & Instructs the payphone to wait for a bong tone. $ Instructs the payphone to wait until either a ring or busy signal is detected.Sample Outpulse Rule
The following rule will:
- Dial speed-dial number 6: S6
- Wait for a 400 Hz tone: T
- Dial the phone's ANI: A
- Send the calling card entered by the patron: C
- And then wait for a reply from the validation service: E
- Which was defined as either 99 for "Valid Calling Card" (O99) or 11 for "Invalid Calling Card" (B11).