Comp 346/488: Intro to Telecommunications

Tuesdays 4:15-6:45, Lewis Towers 410

Class 1

Optional reading (Stallings 7th -- 9th editions)
10.1, 10.2, 10.3
Chapter 1: 1.3, 1.4
Chapter 2, 2.1-2.6, especially 2.3 on TCP/IP

Topics

Basics
 
What is telecommunications? How is it different from data communications?

Phone system: 135 years old (Bell Telephone Co was founded in 1877)
Public internet: barely 20 years old (started 1991)

How many songs, comedy bits or movie scenes involve telephones in crucial ways? How many involve computers? Only count scenes with emotional content!
    Sylvers, Hot Line
    Lily Tomlin, “We don't care [about your poor service]. We don't have to. We’re the Phone Company.”
    Dial M for Murder
    Chuck Berry / Johnny Rivers, "Memphis, Tennessee"

To some extent, the telecommunications system is all about real-time traffic. Except some of it is not even digitized, and much of the rest is not packetized. And voice traffic is low-bandwidth. (The tReadingrend seems to be towards greater and greater packetization.)

Characteristics of voice traffic:

The magic 64kbps number comes from 8-bit samples taken 8000 times per second. This is known as the DS0 rate for digitized lines. This is in universal use in North America. Sampling at 8000 times/second means, as we shall see, that frequencies up to 4000 Hz are preserved. When we look at ultra-fast SONET protocols, we'll see that no matter how large the bandwidth, the basic frame rate is 8000 frames/second (frames simply get larger as the bandwidth goes up), so one single byte in each consecutive frame always represents a singld DS0 line.

Also: voice is loss-tolerant and error-tolerant! (loss-tolerance unites cell-phone users everywhere!)

Why TCP is bad for voice: the problem is that if a packet is lost, TCP stops and waits for the lost data to time out and be retransmitted. This can introduce very large random delays.

Note that Skype does use TCP, though. (Of course, Skype's sound quality is often bad.)
 
Turnover delay: when you stop talking, and the other person replies immediately, what delay do you perceive? This equals one full RTT (round-trip time). 200ms is annoying here. But sometimes it rises to ~500ms, or more!

Jitter: this is variation in the delay. Suppose most voice packets have a delay of 10 ms, but a few are delayed 100ms. To recreate the original sound, voice packets have to be played back at a uniform rate, with the time lag from creation to playback constant for all packets. You can either:
Fill time: with packet-based telephony, the largest source of delay is packet fill time. Voice data accumulates at 8 bytes/ms. If a packet is 1000 bytes, it will take 125 ms to fill, resulting in a minimum RTT of 250 ms. This is objectionably large. Typically, voice packets contain much less data, as little as 48 bytes (ATM). Skype packets are variable-sized (in part due to compression), but most packets have less than 120 bytes of data.
 

POTS

Plain Old Telphone System
(plugboard model); circuit switching (see Stallings chapter 10.2, figure 10.2)
plugboard diagram
Note the following features of classic-POTS: 
Some topics

packet switching 
 

POTS today:
    FXS (Foreign Exchange Subscriber) and FXO (Foreign Exchange Office) ports (4-wire modular jacks)

FXS ports are the ones you plug (analog) phones into; they connect to subscribers
FXO ports are the ones you connect to the line; the connect to the office

Mixing them up can lead to mayhem (or at least overvoltage), and they have exactly the same shape.

A traditional phone has an FXO port; the wall jack is the FXS port. A typical modem card has an FXO port you connect to the wall jack, and an FXS port that you plug your phone into so you can still call when the modem is not in use.

A modem itself is a special kind of sound card: it translates between "modem sounds" and digital serial-line data.

 

 Timeline

Mostly from www.telephonetribute.com:
 
1793: first commercial SEMAPHORE system, between line-of-sight towers (cf Terry Pratchet's SF novel Going Postal)
1844: Samuel FB Morse demo of telegraph: "What hath God wrought?"
1860: end of commercial semaphore
1875: first speech by Alexander Graham Bell: "Mr. Watson, come here, I want you"
1876: first patent; offered to Western Union for $100K. Western Union refuses: "Furthermore, why would any person want to use this ungainly and impractical device when he can send a messenger to the telegraph office and have a clear written message sent to any large city in the United States?"
Edison invents electric motor & phonograph
1877: AG Bell and Thomas Watson form Bell Telephone Co
1880: 30,000 telephones in US
1882: Bell buys Western Union
1884: phone service between NY and Boston
1890: Herman Hollerith 1st punchcard contract for census
1892: Almon Strowger, St Louis undertaker, develops dial phone
          Phone service between NY and Chicago. You went to a special ATT office to place your call.
1894: Bell patents expire
1899: Brown Telephone Co founded; later to become Sprint
1906: Lee deForest invents the vacuum tube, the first way to amplify audio signals
1907: Theodore Vail returns as CEO of ATT; founder of end-to-end policy (control everything from phone to phone)
1913: 1st US antitrust suit against Bell system
1915: 1st use of vacuum-tube amplifiers on trunk lines; 1st transcontinental call
1922: Alexander Graham Bell dies
1949: US sues ATT to divest Western Electric, ATT's manufacturing unit
1951: First direct-dialed long-distance call
1956: consent decree: ATT could keep Western Electric but could only make telephone equipment, and had to license its patents
1956: Hush-a-phone decision: allowed customers to add things that did not affect the network (like acoustic couplers)
1968: Carterphone decision: customers can add "customer premise equipment" (own phone, fax, etc)
1973: Robert Metcalfe invents Ethernet, at Xerox
1978: final implementation of Carterphone decision
1981: Bell divestiture trial begins; Judge Greene presiding
1982: Bell settles suit
1984: divestiture: ATT spins off the "seven sisters":
Ameritech     - acquired by SBC, 1999
Bell Atlantic     - acquired GTE, changed name to Verizon
Bell South    - acquired by SBC/ATT in 2006
Nynex        - acquired by Bell Atlantic, 1996
Pacific Telesis    - acquired by SBC in 1997
Southwestern Bell: changed name to SBC in 1995, bought ATT in 2005 & changed name to ATT
US West    - now owned by Qwest
GTE was also a full-sized phone company.
1986: Sprint "pin drop" advertising campaign, announcing an era of long-distance quality equaling local-call quality. Sprint had the first all-fiber network.
2005: ATT bought by SBC, which changes its own name to ATT
 
Telephony issues:
 
Digitization; encoding of voice
Sampling rate, 8-bit v 16-bit encoding
 
Selling data-transmission lines (ISPs, WANs)
Cellular phones

Echo is a constant problem with phone systems. One source of the echo that you hear is your voice coming out the other party's handset, into their microphone, and back over the line to you.

If Alice and Bob talk to each other using skype, and Alice hears a lot of echo while Bob hears none, a likely possibility is that Bob is using his speakers, and his microphone picks up a lot of speaker sound, while Alice is using headphones and a mike that does not pick up any headphone sounds. That is, the echo Alice hears is "Bob's fault". This kind of echo is called acoustic echo.

There is another, more unavoidable, form of echo. There are two wires run to an analog phone. At some point relatively near the phone, the two wires go into a special transformer called a hybrid and the output is two pairs of wires: one pair for each direction. The signals then travel separately in each direction, until they are recombined by the hybrid at the other end. Hybrids create a certain amount of echo, due to imperfect signal separation. As with the skype situation, the echo you hear is the result of "leakage" at the hybrid at the other end. The downside of hybrid echo is its inevitability (headsets don't help); the upside is that the echo delay is absolutely fixed, and so echo cancellation is feasible (or at least a lot easier; there are now real-time acoustic-echo cancelers).

Software echo cancellation is cpu-intensive; this is best done in hardware.

Asterisk

Hello, world demo (every computer class has to have this)
Note that no actual phones needed to be configured for either of these demos.

Now a demo of dialing from AT&T to 773-409-xxxx, and having the cisphone ring.

Demo of dialing from the cisphone to the classroom phone (312-915-xxxx)

Demo of dialing from the cisphone to internal extensions

Helloworld note: apparently the voice is Allison Smith.

Demo of call from SIP phone to classroom phone, and vice-versa.

The first time I did  I managed to forget to hang up after a speakerphone call from the classroom to my 815-828-xxx SIP line (while I was trying to demonstrate voicemail-to-email). I was connected for 9625 seconds (2.5 hours), costing me $1.93.
Dest
 Direction
 CallerID
 Start (converted to CST)
 Duration
 Cost
18158286071
 Inbound
 13129157992
 2012-01-17 18:35:36
 9625
 1.932

Sigh. luser error.

I did subsequently add the following to my sip.conf:

How can we estimate RTT? (I got ~180 ms in my office). One way is the "tapping method": try to tap the phone at a rate where each tap coincides with the echo of the previous tap. Then check the time needed for 10-20 taps, and divide.

Now call the SIP phone from my cellphone. What is the RTT?

Call extension 2000 from the cisco phone, while watching the Asterisk "console". What happens?

Now call 2001.

I wanted to change from CALLERID(num) to P-Asserted-Identity. But if the latter is empty, nothing happens, and it is empty if I call from my own phone. So let's change it to the 773-409-4359 number.

Note: an Asterisk extension is like a script, triggered by a matching dial pattern. It might be a literal extension, but it can be other names too. The Dial command tries to connect that number to a channel, defined in sip.conf.

If the Dial command times out, we generally want to pass the call on to voice mail, but not if the Dial command completes a call!



The Asterisk open-source telephony project was started by Jim Dixon (hardware) and Mark Spencer. Dixon was a telecom engineer who worked with ATT 3b20's, and noticed that PC hardware was, in theory anyway, catching up (or surpassing it). Around 1999, for an early Pentium system, he developed a card with FXS and FXO ports. Because this promised to revolutionize telephony, he named the cards for Emiliano Zapata, the Mexican revolutionary.

Our (internal) phone switch has an analog TDM410 card, with 3 FXS ports, 1 FXO port, and hardware echo cancellation. Though asterisk also now runs on ulam2.cs.luc.edu, with a static IP address.

Asterisk can be used for many things (for example, it makes a darned fine answering machine), but one of the most basic is as a private phone switch, known in the telecom world as a Private Branch eXchange, or PBX.

Basically, a phone switch (Asterix or proprietary ATT or something else) consists of:
We'll ignore call set-up for the moment. While you are making a call, your voice data is collected one or two bytes at a time by the card with the FXS port. The CPU is interrupted regularly, and the card driver turns that voice sample over to the telephony software. The software figures out which call it's part of, and puts the sample into the outbound-voice queue of the appropriate outbound port.

One call can thus involve up to 8,000 interrupts / second. For CPUs, this is not a very big number, although some older motherboard designs made interrupts very expensive. The Zapata cards buffer the data 1ms at a time (8 bytes), so they interrupt the CPU once per ms (probably independent of the number of calls). With efficient interrupting (and perhaps some buffering), a standard single-cpu PC can easily support 24 lines.

An alternative to FXS ports on cards is a channel bank: a hardware device with 24 FXS/FXO ports on one side and a T1 line on the other. T1 lines are, in the telecom world, bundles of 24 DS0 lines. You then connect the PBX to the T1 (using a T1 card).

Asterisk voicemail

To get your messages, dial your extension and press "*". Then dial your password, normally the same as your extension.

Note that asterisk can be configured to email you your messages (in addition to leaving them in your mailbox).

Demo of voicemail/email

Loyola has had some interest in this feature for at least fifteen years, but with the Audix system it is too expensive. (Also, we asked once, and were told, "nobody ever asked us for that before!")

To set up an asterisk PBX that does not connect to the larger world phone system, you can assign exensions arbitrarily. But in the real world you have to get numbers from your provider.

If you are buying a separate line to the telco office for each of your phones ("line" in the sense of both the physical line and the accounting), then you don't need a PBX.

If you're setting up your own PBX, you need
Question: how many trunk lines do we need? If at any moment we have more people wanting to call out than we have lines, some of them will get the no-trunk-available signal (traditionally the "fast busy" or reorder signal). The number of trunk lines should exceed the peak-hour average number of outbound calls, but exceed by how much? The margin of safety needed gets smaller (at least as a percentage) as your organization gets larger.

Suppose we have a small number of trunk lines from the telco that come into our PBX FXO ports, and many more internal phones connected to our PBX FXS ports. Outbound calls are straightforward: the telco doesn't really need to know who's placing the call (except that we may want to cooperate with Caller ID by providing "CID" information). But what about inbound calls? To which internal phone should it be routed? Typically, we get a block of phone numbers from the telco, and use those (or straightforward mods of those) for our internal phone extensions. Then, when an inbound call arrives, our PBX uses Direct Inward Dial, or DID, information attached to the beginning of the call (often in analog form) in order to identify the desired extension. The PBX then connects the call to that extension.


Basics of packet switching

packets
addressing
routing/switching
Simplest routing: every switch keeps every destination in a table
Fairness issue of packet max size. This is particularly important if 1500-byte large packets are intermixed with 80-byte voice packets. (RTP voice packets are usually 160 data bytes.)

How does having a fixed bitrate differ from having a designated bandwidth? 

Two problems: fairness and queuing delay / jitter. 
 
PACKET "switching": users send individual bufferfuls, called PACKETS. Think ~1KB, although much smaller packets are also in common use. After one user is done, someone else has an opportunity to send.
 
Consider packets: with 16 users all sharing a 1Mbps line (1 bit/microsec, 1Kb/ms), each gets 64Kbps if divided equally.
 
If.
 
There is, in fact, no guarantee of equal division, though, with packet switching. Ethernet does not guarantee this, IP does not guarantee this. (Token Ring guarantees that each active sender gets an equal share of the number of packets sent, but this means senders with smaller packets get to send less data. And besides, token ring does not scale well.)
 
The whole point of packets is that you can send more if you have to:  packet-switched LANs support BURSTY transmission.
 
Furthermore, even if there were fairness, we have great irregularity at the small scale. If soneone sends a 1.25KB (10Kb) packet, the line is tied up for 10 ms. Someone expecting 64Kbps would pile up 640 bits in that time. Yes, they can be queued, but they will certainly arrive late.
 
Some delay is inevitable. But telephony users would like to see consistent delay, not random delay whenever some other user sends off a big packet we have to wait for.
 

3-7 layer models
layering as software engineering
    protocol graphs: ARP, video/audio system, etc
 
TCP/IP 4-5 layer model
OSI 7-layer model: problems with presentation & session layer
 
QUESTION: is it legitimate to separate the Internetwork (packet-delivery)layer from the transport layer? Is it a good idea?
 
Clearly, there are cases where commingling the LAN and IP layers makes sense:if there is no need to accomodate different low-level LAN protocols. If you are building closed systems (eg if you are The Phone Company), that might happen.

Fig 2.3, p 39 (9th edition): what layer is ATM?


Intro to TCP/IP

see http://ulam2.cs.luc.edu/ebook/