Let's face it. The communications industry is jargon filled to the point where we come off like a secret society. Our acronyms are the secret handshakes that either let you into the club or keep you out in the cold.
Unfortunately, I have run into some very capable people who feel embarrassed to admit that there are some concepts and terms that they don't fully understand. They may actually use the words or phrases in conversation while not completely grasping their meaning. They may even be using them with others in the same boat as part of a mutual misunderstanding society.
For the next page or so, I would like to take a look at what I think are the most common aspects of IP communications that are misconstrued, misinterpreted, or downright miscomprehended. I will start with the easy ones and work my way down to the harder, yet just as important, technologies.
Are you ready? Let's go.
Codec
I speak to companies and user groups across the country and bandy this word about like I would say "house" or "automobile." I expect that everyone in the audience knows exactly what I am saying, but every so often I see a look on a face or get a question that tells me that it's not as universally understood as I would like it to be.
A codec (coder-decoder) is a device or technique to convert analog signals such as audio or video into a digital format and vice versa. In addition to converting these signals into a form that can be transmitted within IP packets, codecs significantly reduce the amount of transmitted data. They accomplish this by limiting the frequency range of the data they process or by compressing the data – or both.
Common audio codecs are G.711, G.729, G.722, and the more recent addition to the family, Opus. Common video codecs are H.264, H.265, and the newer VP8. Each has its pros and cons. Some were designed to minimize the amount of data required to reproduce a conversation while others are more concerned with creating the best audio or video experience. Typically, higher quality codecs produce larger packets and consume more bandwidth.
While you don't need to know the nitty-gritty of every codec, it's important to know why different codecs are required to solve different problems. It's also necessary to know that some codecs have no part to play in some of the newer communications. WebRTC and G.729? It's not going to happen.
For a deeper look at codecs, please refer to my article, A Practical Guide to Audio Codecs.
RFC
A Request for Comment (RFC) is a publication of the Internet Engineering Task Force (IETF), the organization that creates standards for Internet and Internet-related technologies. For example, RFC 793 defines Transmission Control Protocol (TCP), RFC 3261 defines Session Initiation Protocol (SIP), and RFC 1541 defines Dynamic Host Configuration Protocol (DHCP).
It is important to know that an RFC by itself is not a standard although it may become ratified by the IETF and eventually designated as a standard. Unfortunately, some unratified RFCs have been treated as standards and implemented into widely distributed products. For instance, RFC 5806 defines SIP Diversion, and even though it was never ratified, its constructs have been incorporated into a number of solutions. This causes incompatibility when those products interface with those that implement the History-Info standard (RFC 4244).
RFC 4733 and RFC 2833
Speaking of RFCs, RFC 4733 (formerly RFC 2833 and still commonly referred to as such) is one of the most important of the misunderstood standards -- yes, this RFC has been ratified. Simply put, RFC 4733 defines an out-of-band method for sending DTMF (Dual Tone Multi Frequency) digits on an IP connection. That means that instead of mixing DTMF with spoken audio, the tones are packetized and sent on one media stream while human voice travels on a separate media stream (e.g. G.711 encoded voice).
You need to have a decent awareness of RFC 4733 if you expect to use a Codec like G.729 on your SIP trunks and allow your users to enter touch tones on their calls. That's because G.729 does not support sending DTMF digits. In this case, RFC 4733 is absolutely required to pass them along.
I won't get into the mechanics of how this works. It's enough for you to know that the two media streams exist in order to properly provision SIP trunks, session border controllers, and communications servers. Failing to understand this RFC will lead to unusable IVR (Integrated Voice Response) units and very unhappy customers.
Signaling Protocols
One thing that we don't lack in today's communications technology are choices. Depending on the maker and vintage of your system, you might use SIP, H.323, Skinny, UNIStim, or any number of other standard or proprietary signaling protocols to make and manage calls. It's also not uncommon for a single system to use more than one depending on the endpoint or network requirements.
In all cases, signaling is not media. For instance, SIP is used to establish a call between two endpoints, but it is not used to transmit G.711 or G.729. Sure, it's involved in setting up the media stream, but that media stream is not SIP. Technically, it's a protocol called Real-Time Protocol (RTP) and the media itself is described by yet another protocol, Session Description Protocol (SDP).
You need to be aware that even though something is called a standard, liberties have been taken by various vendors and one implementation may have issues working with another implementation. This is certainly the case with SIP, where Nortel SIP looks different from Avaya SIP, which looks different from Cisco SIP. Thankfully, products like Session Border Controllers and Session Management servers have the ability to adapt SIP from one vendor to look like SIP from another vendor.
For another look, please refer to The Trouble with Standards is that They Rarely Are.
Transcoding
Transcoding converts one codec into another. This can be required for a number of reasons, but one of the most common is a device or service that is limited in the number of codecs it supports. For instance, you might use G.729 on your SIP trunks, but have a voice mail system that only speaks G.711. In this case, you need to transcode from one codec to another.
Transcoding codecs doesn't magically make the outcome sound better. G.722 is a great sounding wideband codec, but you can't transcode G.729 to G.722 and expect it to sound as good. Transcoding formats the bits and bytes into a different format, but doesn't add frequencies and data that wasn't originally there. In other words, transcoding is strictly for compatibility.
WebRTC
Web Real-Time Communications is a technology that allows Web browsers (and other HTML-based interfaces) to send and receive real-time media. For instance, WebRTC allows you to go to a webpage and use that webpage to make an audio or video call. The resultant media is sent directly and securely from your device to the recipient's device.
Finance, customer care centers, health care, and education will likely be in the forefront of the most significant WebRTC applications. Imagine click-to-call or click-to-video buttons on every company's webpage. Personally, I would rather point and click than pick up a telephone handset to dial an 800 number.
WebRTC is a disruptive, revolutionary technology that stands toe-to-toe with the biggest changes we've seen in the communications space. This is something that you must pay attention to if you plan on having a future in this industry.
Join the Club
This should be enough to get you started. It's my hope that someday articles like this won't be necessary, but past experience tells me we all have a lot to learn. I'm good with that, though. There are lots of things that I don't know and hope that my industry peers enjoy learning new concepts, phrases, and terms as much as I do.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.
Follow Andrew Prokop on Twitter and LinkedIn!
