Switching to VoIP
4.3. Customer Premises Equipment
Any equipment installed by the telephone company for use in terminating voice calls or other connections is called customer premises equipment (CPE). In most small offices, CPE isn't used, and the occupant just plugs in a conventional analog phone or two. But in situations in which the telephone company itself manages the customer's PBX or manages a private voice trunk on the customer's behalf , then the PBX is called CPE. The softPBX described in Chapter 3 would be considered CPE if it were managed by the telephone company. 4.3.1. Switches
When you hear somebody refer to a switch that resides on the customer premises, that usually means a PBX or a KSU. See Chapter 1 for a refresher on PBXs and KSUs if needed. 4.3.2. The Demarc
The Demarc, or demarcation point, is the point at which telephone company-owned facilities terminate. Usually a cross-connection point or wiring terminal near the exterior of a building or outside it, the demarc is where the phone company's wiring connects to privately owned facilities. Typically, the demarc is where the phone company's troubleshooting stops, as well. 4.3.3. "Inside Wiring" and the Cable Plant
Inside wiring is the privately owned network of communications cabling and wiring terminals located on the customer side of the demarc. Inside wiring could be simple, two-pair wiring that connects a bunch of four-pin phone jacks (as in a house), or it could be a centralized distribution of cabling throughout the buildingalso called the cable plant .
4.3.4. CP Distribution Frames
Customer premises distribution frames are cross-connect blocks, terminals, or patch panels where endpoint locations are aggregated and centralized. Like the PSTN equivalent, CP distribution frames make it easier to move connections from one tenant to another in the same building or from one desk to another in the same office. These frames are most often used with twisted-pair cabling of Cat3 or Cat5 grades. CP distribution frames are often accompanied by data networking gear like switchesdevices that connect devices to the "edge" of the network. This is the proverbial "data closet," a place where telephone wiring and data networking equipment reside. 4.3.5. FXS and FXO Signaling
Foreign exchange station (FXS) refers to the signaling used by switch interfaces that serve analog telephones. An FXS interface is on the switch, with a phone connected to it. Foreign exchange office (FXO) refers to the signaling used by telephones or PBX systems that are subscribers of the CO switch. These switches are either COs or PBXs. An FXO interface is on a phone (or PBX) that is connected to a port at the CO.
4.3.6. Loop Start Signaling
In order to establish an analog phone user 's intent to begin a call, electromechanical signaling is used. Really, this is just a fancy way of saying that, at the outset of a call, a phone is lifted from the hookthe local loop is closed, and current begins to flow. This current becomes the sound of the dial-tone in your handset's transducer. The method of closing the loop at the hook switch to start the call is called loop start . It's by far the most common method. Less-common variations on this theme include ground start , ear and mouth , and several more. Usually, these methods are used with PBX trunks and not residential phoneswhich are almost always loop start devices. 4.3.7. Channel-Associated Signaling
A digital cousin of FXS and FXO uses an in- band or "robbed-bit" approachthis is called channel-associated signaling, or CAS. Digital telephones and trunks can use CAS. The phrase robbed-bit means that a portion of the digital bit stream normally used for sound transmission is allocated for signaling. Common PRI signaling is not CAS (see the earlier section "PRI/T1"). Unless you use channel banks extensively, you're unlikely to encounter CAS. 4.3.8. Other Legacy Standards
There are probably a half- dozen less-common analog and digital signaling techniques in use; a good description of each is available at http://www.cisco.com/pcgi-bin/search/search.pl?searchPhrase=telephony+signaling. Earlier in the chapter (see the section "PRI/T1"), we covered one of the most important of these standardsPRI. 4.3.9. Project 4.1. Create a Trunk Channel with a POTS Line
4.3.8.1 What you need for this project:
To build a softPBX that can communicate with the PSTN, you'll need at least one trunk channel to communicate with the FXS interface in the CO switch. This channel will provide you with the dial-tone from your local phone company so that calls to and from the PSTN can be handled by the Asterisk server. There's not much to setting up an FXO channel. The quickest way to add one to an Asterisk system is to install an X100P, TDM400P, or similar FXO line card. First, plug the trunk into the X100P card by connecting an RJ11 standard phone patch cord from the wall jack of an active telephone company POTS line into the X100P card (or TDM400P card) in the appropriate port. On the X100P, this port is the one marked with an etching of a telephone wall jack. On the TDM400P, it's the port that corresponds to the slot number of the FXO module you've installed. For more information on the TDM400P and X100P cards, see Chapter 3. Once the card is in a PCI slot on the Asterisk server and the phone line is connected, you've got to define the FXO trunk connection as a channel that is usable by Asterisk. Once defined, you can reference the channel within your Asterisk call-routing scheme. The POTS line can serve as the full-time gateway for all PSTN calls and all telephones in your home or office. Or the POTS line can just be a connection mechanism so that the Asterisk server can answer incoming calls on the POTS line if they aren't answered by a person within a certain number of rings. But firstthe FXO connection must become a named Asterisk channel.
Each voice channel in Asterisk has a number. This number consistently represents the same channel throughout all of Asterisk's configuration files and in its logging output. The numbering of voice channelsespecially those that require a dedicated piece of interface hardware in the serveris determined by the order in which their drivers are loaded and the order in which they are identified in the PC's PCI bus. Figuring out which card is whichsay when you have three or four X100P cards, each with its own POTS linecan be a bit of trial and error. In this project, we're using only one card and one line, so it should be a breeze . The voice channel we're going to create will be called Zap/1-1. Asterisk follows a similar convention when naming all voice channels, even if they aren't analog phone line channels. The channel name is divided into two pieces. The first piece, Zap/1, refers to the physical Zaptel interface channel (which is either an FXO/FXS interface or a PRI channel), while the second piece, -1, refers to the line appearance (more on line appearances later). Assuming you haven't touched the Asterisk configuration files since running make samples, you'll have to do only two quick config changes to fire up your POTS line. The first change will happen in /etc/zaptel.conf . Add the following lines to the end of the file: fxsks=1 loadzone=us defaultzone=us
The first line tells the Zaptel configuration program, ztcfg , to set the X100P card to use FXS "Kewlstart" signalinga variation of conventional FXS loop-start signaling. The reason the number 1 is referenced is because there's only one Digium card installedso it's card number one, and its channel will be 1 as well. If there were two cards installed side by side, that first line would say fxsks=1-2 instead. If there were more than one channel per card (such as the TDM400P), then a single channel number is used for each channel on that card (i.e., fxsks=1-4 for a card with four lines attached). The following two lines localize the FXS signaling functionality of the X100P interface with loadzone and defaultzone . Other valid zones include fr , de , and uk . Now, you may be asking yourself, "Why am I configuring the FXO interface card to use FXS signaling?" The answer is simple: in order to communicate with an FXS device (the interface at the CO), the local interface must use FXS signaling. Remember that only FXS devices can receive signals meaningfully from FXO devices, and vice versa.
The next change you need to make is in the /etc/asterisk/zapata.conf file. The sample configuration should be completely commented out (a semicolon [;] at the beginning of each line). If not, comment them all out by inserting the semicolons. Then, add the following lines to the end of the file: context=default signalling=fxs_ks usecallerid=yes echocancel=yes callgroup=1 pickupgroup=1 immediate=no callerid="* X100P POTS"<(123) 456-7890> channel=>1
The first line tells Asterisk what set of assumptions to make (i.e. what "context" to choose) when handling incoming calls on the POTS line. The second line tells Asterisk (not ztcfg ) what type of signaling the X100P has been set to use. The following lines turn on a few traditional telephony featurescaller ID, echo cancellation, and other stuff that's covered in more detail later. The last line assigns the settings spelled out above it to channel 1. The assignment of these inherited settings uses the => assignment operator rather than just an equals sign ( = ). The Asterisk configuration parser doesn't distinguish between them; the convention is merely for ease of readability. One more quick change you'll need to make to Asterisk's sample configs : change the Zap/g2 definition for $trUNK in extensions.conf to Zap/1 . (This step may not be necessary with earlier versions of the sample config.) This will allow outbound dialing to be directed to the correct channel, Zap/1, the one that represents the connection to the PSTN. Now, since you've added a new hardware interface, Asterisk must be restarted. Once you've done that, try calling the POTS line you've connected to the X100P using a second phone line or your cell phone. After a few rings, assuming you've not changed it in the configuration, Asterisk will answer and you should hear the familiar demo greeting that you heard in Project 3.1. If you examine Asterisk's console output during this demo, you'll see something like this: -- Starting simple switch on 'Zap/1-1' -- Executing Wait("Zap/1-1", "1") in new stack -- Executing Answer("Zap/1-1", "1") in new stack ... -- Playing 'demo-abouttotry' -- Executing Dial("Zap/1-1", IAX@/guest@misery.digium.com/s@default) in new stack ...
Through the console output, you can trace every step Asterisk took to recognize, answer, and process the incoming analog call from the PSTN and connect it using the IAX protocol to a remote server across the Internet. Note that, although this chapter is about legacy, circuit-switched telephony, we're using IAX to get our feet wet with VoIP. Plus, the IAX demo is so easy to run with Asterisk out of the box, it's a great way to demonstrate how a VoIP signaling protocol can be used with legacy signaling in a single PBX.
This is the first project in which we've used a traditional analog device, the phone calling in through the PSTN, with Asterisk. While Asterisk itself is software, traditional PBX systems have long relied upon software-like algorithms in order to allow many analog and digital phones to communicate across a single, shared switching system. Chief among these algorithms is a technique called time division multiplexing , and almost all legacy switches use it to support those old-school phones. |