Image courtesy of stock.xchng

Surprising as it may seem, FAX has been with us for a long time. It was invented in 1843 by a Scotsman called Alexander Bain – 4 years before Alexander G. Bell was born. As the first faxes were sent over telegraph lines, they were actually digital; it wasn’t until the 1980s that they became popular in their analogue form.

FAXing is based on a ‘recommendation’ ratified by the ITU (International Telecommunications Union) called T.30. The fact that it is a recommendation rather than a specification has always been a bit of an issue for fax manufacturers as there is no formal way to say ‘this device conforms to the specification’, instead each device manufacturer has to bend their implementation to work with other devices in the field.

There is a feeling in some quarters that the FAX machine has ‘had it’s day’, although there is still a huge amount of fax traffic over the planet at any given time today; that coupled with newer protocols like fax-over-IP (T.38) means that fax is going to be around for some time to come.

FAX gained business and residential acceptance mainly with the advent of ‘Group 3′ fax, or that mandated by the T.30 recommendation. Prior to then it was something of a free-for-all in the fax machine market with each vendor having their own implementations and protocols. There is still an option for vendors to ‘duck’ the recommendations by implementing the NSF (Non-standard Facilities) function which pretty much provides a back-door to the protocol.

ITU T.30 is something of an umbrella protocol referencing into several other ITU recommendations to give it the functionality that it requires; mainly these are the V. series modem recommendations and the T.4/6 compression recommendations.

Take the slow train

Image courtesy of stock.xchng

In today’s terms FAX is outrageously slow; note the following modems (see Noakes Knowledge) for the kind of speeds that FAX is able to run at:

• V.27(ter) upto 4,800bps
• V.29 upto 9,600bps
• V.17 upto 14,400bps
• V.34 upto 33,600bps

Note that my (extremely cheap) broadband connection currently runs at 8,000,000 bps; so fax is a really slow way of transmitting data. That said, there is a common held belief that fax is point-to-point and as such has a slightly higher legal standing than Internet data document transfer; a viewpoint becoming increasingly eroded.

T.30 uses a really slow modem, V.21, to get going. V.21 runs at 300bps and is used to allow the fax machines at each end of the call to work out how fast they may be able to send their pages at. A typical fax call is thus broken into a number of ‘phases’ these are:

• Phase A:
  • Exchange of tones to establish that this is a fax call – these are the annoying beeps that you hear if a fax machine calls you by mistake.
• Phase B:
  • An exchange of capabilities – this allows each end to choose the best fit of their abilities
• Phase C:
  • Sending the page at the fastest agreed speed
• Phase D:
  • Confirmation that the page transmission was OK
• Phase E:
  • Release (Hangup) of the call.

There are obviously numerous other flows and sub-flows of a fax call depending upon what happens if things go wrong. For instance pages can be re-transmitted, speeds can be changed / renegotiated and so forth. This blog is not the place to show all those flows – they span several pages of dense A4 diagrams to fully display, so let’s not do that here.

Paint me a picture

Image courtesy of stock.xchng

One final question is “how does a fax machine turn a page into a signal and back into a page again?“.

The basics are pretty simple, to send a page a fax machine acts as a scanner – the page is passed over a device that essentially detects black (non-white in reality) and white and turn them into 0’s and 1’s.

This binary data is then transmitted over the appropriate modem, described previously, and then recreated at the other end by taking the 0’s and 1’s received and using them to print the original data.

The print-out stage used to use thermally sensitive paper and a write-head that would heat-up and cool down very rapidly – which is why it was never a good idea to leave your fax near a hot radiator! Many fax machines still use this technique, whilst others (most noteably combined printer/scanner/fax machines) use other methods such as inkjet printing.

Obviously, scanning a page of A4 into many hundreds/thousands of lines, each of which contains many hundreds/thousands of 0’s and 1’s means there is a lot of data to send. Given the slow transmission speeds we’ve seen previously this would make fax transmission impracticle, so how is this dilemma resolved? Simple, by compressing the data.

Fax compression uses a technique called Huffman run-length encoding, a nifty little method by which the most commonly occuring lines or sections of lines are reduced to short “code-words”. In an average fax, there will be a lot of blank lines, so for instance, lines that are all white are described by a very short code-word of only a few bytes. This method allows huge reductions in the amount of data to be sent.

All faxes use this method of compression, referred to as “Modified Huffman” or MH. Many fax machines can also employ additional enhancements, such as “Modified Read” or MR which uses MH for the first line and then takes the next line, compares it to the first and only sends the differences. This again improves data compression as many fax lines don’t vary hugely from line to line. (Remember that in the world of fax, a line isn’t a line of text, it’s a line of scan – which can run into the hundreds per inch). MR only runs over a set number of lines before it again uses MH to take an accurate line “snapshot” – this is because errors that occur on an MR line can propogate easily (as there’s no baseline between successive MR lines). There is an extension to MR, known as “Modified-Modified-Read” or MMR in which the number of lines between the MH snapshots is increased on known-good lines.

So all of the above is what it takes to get a page sent from one place to another -  Alexander Bain would be impressed to see his idea still in use almost 200 years after he first invented it.

Image courtesy of stock.xchng

We saw in SIP 101 how a VoIP call is first setup, maintained and then hungup at the end. As you’ll recall this is known as the signalling part of a call; fine in principle but useless if you can’t actually hear the person at the other end. For that we need to get some audio flowing and that’s where RTP comes in.

RTP stands for ‘Real Time Protocol’ and is, as its name suggests, concerned with getting data from one place to another in as close to realtime as possible. (For the technically minded out there RTP is laid out by the IETF under RFC3550.)

There are many advantages to using IP as the carrier, or media transport, for a voice or video call: you need only send data when you need to; the infrastructure is plentiful and inexpensive; you are not constrained to using ‘plain old telephony’ bandwidth (the ’size of the pipe’) so can use technologies such as ‘high definition voice’; data and audio can be combined to provide rich communication experiences; the number of devices that can receive the traffic is huge and the list goes on and on!

Image courtesy of stock.xcnhg

There is a disadvantage though – IP was not designed to handle ‘real time’ communications. Think of an email; whether it takes 0.001s, 1s, or 20s to deliver the email, the receiver will not really care. Similarly loading a web page might be annoying if it takes a long time, but no lives will be lost on the back of it! Audio and video are different though, they have real time constraints, and we will look at some of the impacts of that here.

IP communications involve breaking large lumps of data into smaller chunks known as packets. If you download a song from your favourite mp3 vendor, you don’t actually get the whole thing in one go (even though it may feel that way), your computer is sent a very large number of packets which it then combines together to form the whole song file. As downloading a song does not need ‘real time’ capability it is usually done using a system known as TCP (Transmission Control Protocol). Under TCP, each packet can be checked to make sure that it has arrived, and that it has arrived without being ‘damaged’ in transit. A missed, or damaged packet will be sent again so that a faithful reproduction of the original file can be created by your computer.

In a real time environment there is no point in trying to correct a broken packet, or request the retransmission of a missed packet…. the moment has passed. Imagine that I am sending the following in real time (and for the sake of argument, I am going to assume that each word written below can be digitised and sent in a single packet).

“The rain in Spain falls mainly on the plain.”

If the receiver is listening to this on a phone, and the phone misses packet 4 (Spain), they will hear

“The rain in ……. falls mainly on the plain.”

By the time we realised we’d missed a word, it’d be too late for the other end to send it again as we’d already be into the rest of the sentence. It would be odd if at the end of the audio the word Spain was suddenly inserted, and where would you insert it if the speaker carried on talking?

In reality, actual audio is sent in much small packets than this (typically between 10 and 30 milliseconds of audio per packet) but even so there is still no real point in checking or correcting the packets, so RTP usually uses a much lighter weight underlying protocol known as UDP (User Datagram Protocol) that doesn’t have any of the data delivery guarantees of TCP but doesn’t suffer from the potential large scale, round-trip delays either.

This leads to the problem of what do you do with packets that either never arrived, or arrived broken. The problem is compounded by the fact that IP is a ‘best effort’ delivery service. No packet is ever guaranteed to arrive, and there is no guarantee as to when it will arrive. The fact that a packet sent from London to San Francisco could go the shortest possible route, or via Hong Kong means that there is an inherent variation in the time it takes packets to go from one place to another. This variation in delay leads to what is called Jitter.

If I send out packets on a heartbeat as follows

s) 1….2….3….4….5….6….7….8

They may be received as

r1) ..1….2….3….4….5….6….7….8

which has just introduced a short delay, or they may be received as

r2) ….1…….23…….4..5………….678

which takes more dealing with or

r3) ….1…….23…….4..5………….786

which takes even more dealing with!

The way to address this is by using a ‘jitter buffer’. A jitter buffer is basically a software mechanism that inserts an artificial delay into the audio playback so that there is some room to breath if packets come in later than expected. In the case of r1) we would need a .. delay in order to be able to play the audio out without problem. In the case of r3) we would need a ………….. delay to be able to play all packets out in sequence. The most sophisticated jitter buffers are ‘adaptive’ which means that they actively change the introduced delay so keep it at the minimum possible.

Two issues come from this. What happens if our jitter buffer isn’t long enough to handle the delay, and what is the impact of introducing a delay into a phone call?

Well, if the packet arrived outside the time that our jitter buffer catered for, or not at all, then we need to have a concealment strategy. Usually this is just to play silence for the period that the packet covered, although there are several more sophisticated techniques which avoid the ‘clicking’ that can occur if a lot of packets are missed at once. Most often this concealment is not noticed by the listener; however, potentially whole words could be lost; a problem if you are trying to tell a sales guy “I don’t want to sell at that price” and the “don’t” goes missing – expensive!

Delay is another problem as IP is an inherently high-latency (a $5 word for delay) transport method. Delay effects different types of calls in different ways. On a sales call with a lot of questions being asked and answered, the effect of delay can be severe… if my call introduces 1s of delay, then it will take 1s before I know that my client has interrupted me, and a further 1s before she knows that I have responded to the interruption. This is not good. However, when talking to my mother-in-law I am subjected to one way traffic, and the effects of delay are minimal!

In reality, delays inherent in good, modern, local networks (LANs) are suitably low enough to make VoIP (using RTP) an obvious choice; that’s why many businesses are moving to replace their conventional TDM based internal PBXs with VoIP based ones. For longer hop networks (WANs and the Internet) VoIP can still be a good and powerful choice – providing that the infrastructure is good enough to minimise transmission delays and packet loss.

Image courtesy of stock.xchng

So how does all this fit together to make the entity known as RTP? Quite easily as it happens: RTP simply takes the data stream being sent (audio, video etc), breaks it into suitable chunks (to go into the UDP packets for transmission) and adds some extra information such as the type of the data (e.g. the audio format being used), the packet sequence number (so that packets arriving in the wrong order can be rearranged) and some timing information (so that delays can be worked out correctly). It’s then up to the receiving end to take the packets, reassemble the audio as best it can, account for any delays and play it out so the user can hear it.

Image courtesy of stock.xchng

When making a phone call two things have to happen: firstly the call has to be placed (one person dials, the other person’s phone rings, they answer and so on) and secondly the two parties have to be able to have a conversation (audio must flow). In technical terms placing the call is a type of signalling, the actual speaking is a form of media exchange.  This dual technique of signalling and media is used in every phone call around the world and VoIP is no different. In VoIP there are a number of ways of signalling a call, SIP happens to be the most widely used and the most likely to become the de-facto standard for VoIP communications.

SIP stands for Session-Initiation-Protocol and is, as you’ll have guessed a signalling protocol used to set up media sessions such as voice or video calls, but it can, and is, used to set up pretty much any type of collaborative activity.

SIP sends its data as human-readable text (if you’re an engineer) between one of more parties in an attempt to create a common session for them. For the purposes of this blog posting, we will look at what happens when a SIP capable phone tries to make a call to another SIP capable phone; it makes no difference if the phone is a desk phone, a softphone running on a PC, or a SIP client running on a mobile device.

SIP borrows heavily from the http protocol (used by you, right now by viewing this web-page) and uses what are called URIs (Uniform Resource Identifiers). Don’t let the jargon put you off, URIs are the same things that you see in website addresses and email addresses of the form yourcompany.com, the only difference is the bit at the front – http: for web, mailto: for email and sip: for, guess what, SIP.

So to contact me at Noakes, you could use mailto:simon.millard@noakesltd.com for an email, or sip:simon.millard@noakesltd.com. Generally SIP phones will work happily without the sip: at the front (they’ll add it in for you automatically, in the same way a browser doesn’t need the http: bit).

SIP sessions follow what is known as the request/response model; it’s pretty simple, one end will send a request and the other end will send a response. The fine details of what’s allowed in each part is where the SIP protocol specification comes in; for those who really want to know you can find the gory details in the IETF specification RFC3261; personally I wouldn’t recommend it, Noakes is here to read such insomniac delights so you don’t have to.

Image courtesy of stock.xchng

SIP calls are usually started using the INVITE command (it really is the word INVITE, with lots of other associated settings and fields). The calling phone (the one which dialled the ‘number’) will send the INVITE message. Using the same Internet methods that get your email to my mail server, the INVITE message will get delivered to the called phone. The called phone then needs to respond to this request by using the same type of responses found in a web transaction. Usually in response to the INVITE, the called phone will issue a Ringing message and will start making a ringing noise (so the called party knows there’s an incoming call).  When the call is answered the called phone then issues an OK message. If an element in the network decided that the called phone didn’t exist, the response might be a Not Found.

(Old timers amongst you might remember the days when this turned up in your browser as a 404 message if you miss typed the address of a website, it’s no different in SIP, some of the messages, like OK, Ringing, Not Found have the same numeric codes associated with them, 200, 180 and 404 in this case.)

In the event that an OK is sent back to the calling phone, an ACK message is sent (for Acknowledged) – and the session is up and going. To end the session either party can send a BYE message. All in plain text and nice and easy to understand and troubleshoot. In reality, there’s a couple more messages that get passed around but the main gist is as above.

Unfortunately the fact that it is plain text, nice and easy to understand and troubleshoot is a bit of a weakness if you don’t want everyone on the network to know who you are calling – in much the same way that you may not be happy sending your credit card details over the Internet when anyone could be listening. To get around this problem SIP has been extended to use a protocol called TLS (Transport Layer Security) to provide some protection to your data. TLS encrypts the SIP traffic so that it is useless to an attacker. TLS is the same protocol used to secure your credit card transactions over the Internet – you can tell when a page is using TLS as a lock symbol will usually appear somewhere on the browser.

The last thing to mention about SIP, is that it carries another protocol inside called SDP (the Session Description Protocol) which both ends use to determine what is actually going to be carried out by this call; is it a voice call, a video call, or some other transaction. For a phone call, SDP is used to set up how the voice traffic will be sent from one phone to another. See Noakes Knowledge on the Real Time Protocol if you would like to know more.

Image courtesy of stock.xchng

One way to think about the difference between SIP and SDP is to imagine you receive an invitation to a party through the post; SIP is the envelope – it has the recipient’s address on the front, a return address on the back and possibly a hint of what’s inside (“this is not a circular – important party invitation enclosed”). The SDP is the invitation itself, saying where the party will be, at what time and what to wear. In reality most people in the industry tend to use the term SIP to include both SIP and SDP in the same context.

So that’s SIP in a nutshell, a text-based protocol that’s used to control voice and video calls over an IP network. It can, and is, used for more than just calls but that’s far and away its biggest use. It’s not the only protocol for doing this but it’s the most popular. Also remember, SIP on its own is no good, you need SDP to actually work out what the calls are going to be and RTP to get the content (audio/video etc.) between the parties in real-time.

Image courtesy of Konrach

Old school vs. New kid on the block

1. Are you sitting comfortably?

Our story begins in the halcyon days when telephone calls were carried over classic telephony networks, provided by such gentle behemoths as BT, AT&T and Cable & Wireless. Known generally as TDM-based systems, these networks were dedicated to carry calls and little else. So people knew where they stood; you used your knife and fork to eat, your phone to speak to somebody and your computer to play Zork.

Then one day dear reader, there came a eureka moment. Someone, who’s name is lost in the mists of time, realised that computer networks could potentially carry voice calls as well as conventional computer data (a digital voice call is simply a series of 0’s and 1’s after all). This new concept was to become known as VoIP, for Voice-over-IP.

Time for a pop-quiz: When do you think VoIP first surfaced as we would recognise it today?

[a] 1990’s
[b] 1980’s
[c] 1970’s.

The answer is [c]  – VoIP has been around longer than many of us think.

At the time of this Einsteinian revelation, the processing speed of computers and the bandwidth of their networks weren’t exactly up to the task in hand; in fact they were, how can we say this politely, rubbish as anyone who dipped their toe into this early frigid bathwater discovered. However, time marches ever onward, computer speeds increase, police officers get younger and thus there came a point where it was practical to use computers and their networks to carry phone calls: the age of VoIP had arrived.

As with many new arrivals VoIP’s birth was a tricky affair; it’s infancy proving relatively long, painful and fraught with false-starts. Early adoption tended to give VoIP a bad name whilst it was still in nappies (diapers for our American brethren) but it has survived through its growing pains into a headstrong young adult, ready to teach the previous generation of geriatrics a few stiff lessons.

2. Neither one thing nor the other.

VoIP can now be found pretty much everywhere within telecommunications; many people use it in some form or another on a daily basis and so the scene is set for a showdown between the old and the new. Let us take a moment therefore to ponder the celebrity death-match that is TDM vs. VoIP, what are the relative strengths and weaknesses of our two gladiatorial combatants?

• TDM is well established and is still the major method of call interconnections world-wide.
• TDM provides guaranteed quality of call and dedicated resources by the use of a circuit/channel based technique, usually based on a 64kbs stream per call (for those technically minded) – that’s just enough to give you a “normal” quality voice call running in a standard format.
• TDM can provide extra services, such as video, but this results in poor quality or the need to combine channels, a process not dissimilar to the extraction of one’s own wisdom teeth.
• TDM requires dedicated infrastructure and maintenance.

• VoIP is a relative upstart in commercial terms and will take time to stabilise and mature.
• VoIP requires additional IP network functionality such as quality-of-service and bandwidth dedication to provide reliable, consistent delivery.
• VoIP is flexible so services such as video can be provided by simply improving the bandwidth available to the call.
• VoIP’s flexibility means that new services can be introduced relatively easily.
• VoIP can be easily secured so calls can be encrypted.
• VoIP can easily provide services requiring higher bandwidths such as high-definition audio and video.
• VoIP can utilise existing IP infrastucture and can be maintained by IP literate administrators and operational staff.

3. Fetch me my crystal ball Igor

Where to next oh learned audience? Well, the ivory towered high-court judges have been ruling for some time that TDM is dead and buried but the public jury has kept returning a not-guilty verdict. The truth is that the picture is unclear and future time-scales somewhat uncertain.

VoIP based systems, most notably SIP, are becoming increasingly commonplace within business premises for internal communications thanks to systems such as Asterisk and Cisco’s Call Manager (the author would like to point out that many other vendor’s systems are also available at excellent prices). They are found in general businesses from the small to large scale and within specialist communications sectors such as call centres and “blue-light” emergency-assistance operations rooms. This all makes good financial sense: you can reduce infrastructure costs and administration overheads by having a common backbone and technologies for all your communications. It also makes computer telephony integration (CTI) far easier.

Long distance domestic calling has moved somewhat to the VoIP camp, with SIP-based, Skype or other systems providing cheap, over-the-Internet calls for keeping in touch with loved ones abroad. Many calling-card platforms and other service providers utilise cheap (if not necessarily good quality) international IP links for carrying their traffic.

Many of the major telcos are considering migrating their core networks (that’s the really, really, big stuff to me and you) to an IP-based backbone. Several, including BT and AT&T, have either already done this or are in the process of doing so. These types of upgrade are expensive, time consuming and not without risk but it’s a reasonably safe assumption to think that all the major carriers will go this way eventually. Now is the ideal time to address one of my personal bugbears and I have plenty dear reader, as I’m sure do you:

When such telco migrations to IP are talked about certain people, who should know better, publicly state that a telco’s move to IP will inherently mean that we, the great unwashed, will automatically and almost immediately move to IP based systems. What’s more, that we will then communicate with that telco using our normal Internet IP address. Just because a telco has an IP backbone doesn’t mean you, I or Aunty Hilda will have an upgrade to IP; so why is that?

A telco’s IP backbone is a super-fast, highly efficient network, designed to carry all sorts of traffic and telephony protocols over it, it just happens to use IP technology at the bottom. Think of it this way, if your electricity company upgraded their transmission lines would you have to throw out all your appliances – no of course not. Or to put it another way my esteemed compadres, do you really think BT or AT&T would give the likes of me and you a direct IP connection into their core network? Sure they would and I’ll just go and get the keys to the Crown Jewels from her Maj.

The truth is that a telco running an IP based network does not have a direct relevance to systems, such as your telephone, connecting to that system. Telcos will eventually completely move to IP interconnects to the home and businesses but these IP connections will be done on layers running far above the telco’s IP backbone.

4. Money, mouth, put

So what do I think? I believe the following to be a fair assessment of VoIP and TDM in the broadest sense. Remember though, this is just my opinion, it’s not completely comprehensive and there are many more views out there.

• VoIP is here to stay and will ultimately usurp TDM.
• VoIP is currently the only mechanism identified for future telecommunications needs.
• VoIP will rapidly become the de-facto standard for businesses’ internal communications.
• IP will become the backbone for all major telecommunications providers:
  • They will use SIGTRAN as a means to migrate their existing SS7 signalling to the IP world.
  • Their IP-backbones will carry many of the standard telephony protocols, probably over a form of MPLS.
  • An IP based telco does not automatically mean their customers will be using an IP phone.
• VoIP to the end users will be predominantly SIP/RTP based.
• Business interconnections to telecommunications providers will becoming increasingly based on SIP trunks rather than E1/T1 links.
• Eventually all domestic users will migrate to VoIP, when this occurs they will notice no (or little) difference in the way calls are made but will have access to additional features.
• Charging for communications will change and may well move to a per-byte basis, rather than a time based mechanism.
• People will continue to use the concept of telephone numbers for a long time to come.
• TDM will go out with a whimper, not a bang.

Until we meet again, take care and remember:

“Only two things are infinite, the universe and human stupidity, and I’m not sure about the former.”  – Albert Einstein

Best regards,

Mark

Just enough information to be dangerous…

Noakes Knowledge is a series of free articles on telecommunications and IT technology, intended for everyone whether you be non-technical, semi-technical or a guru in need of a refresher.

At Noakes we believe that technology should not be a mystery to anyone, so we’ve decided to remove the smoke and mirrors thus arming you, dear reader, with enough fire-power to be able to say “I get it“.

The Noakes Knowledge series is published free and without restriction on its use and dissemination so use it, quote it, copy from it; all we ask is that you pay us a common courtesy by letting people know that you saw the light with Noakes.

We will shortly be demystifying VoIP, secure communications and fax, with many more to come. We’d welcome your input and suggestions on any future topics you’d like to see covered, simply comment on this blog and we’ll see it. We’ll also be announcing any new Noakes Knowledge postings on Twitter, so why not follow us there.

Until we meet again, take care and remember:

“The cure for boredom is curiosity. There is no cure for curiosity.”  – Dorothy Parker

Best regards,

Mark