Wallingford Th. Switching to VoIP / Section 5.1. Application Terminology

Computers & Technology
Education & Reference
Business & Investing
Science & Math

Switching to VoIP
Authors: Wallingford Th.
Published year: 2005
Pages: 43-44/172

<< Previous page
Table of contents
Next page >>

5.1. Application Terminology

Many PBX vendors refer to their telephony functions using words like actions or routes or forwarding plans . Others, the author included, prefer another word: applications . This word is appropriate for a modern, soft-driven telephony world. The words function and action invoke an algorithmic meaning, while application is much more broad and programmatic. Traditional TDM systems and VoIP systems have a similar distinction: TDM is monolithic, rigid; VoIP is programmable, flexible.

But whatever the semantics, things the network can do with a phone call are referred to in this book as applications. They've been organized here in five groups: basic call handling, administrative, messaging, advanced call handling, and CTI. What's covered in this chapter is by no means an exhaustive study of telephony apps. Indeed, while I was busy writing this book, new apps were being developed.

Applications themselves are invented out of necessity and driven by market forces more than by the creativity of technologists. When the market demand for certain functionality reaches a boiling point, a vendor or a group of vendors produce a solution to the demand. Sometimes the solution is submitted to the ITU, ANSI, or IETF for recommendation as a standard.

Not all applications are standards-based. Not every feature in a shiny new Avaya Communication Manager PBX is enabled by SIP or some other open IETF or ITU recommendation. In fact, most PBX vendors, even the ones making commercial-grade VoIP servers, deliver a majority of features using their own proprietary methods . Telephony equipment manufacturers are constantly competing on the basis of features, and often the open standards don't support the features the market is looking for. The standards have to be augmented, and this takes time. The 802.3af standard (power over Ethernet) was ratified in 2003, several years after Cisco had begun shipping its own proprietary solution to the need it addressed. The standards bodies may not have a published recommendation for a certain feature until years after the feature itself is made available in proprietary form.

So, while Cisco, Avaya, and Nortel all have rudimentary SIP call-signaling support functions , they all offer a much broader selection of telephony applications through their own closed, proprietary, or "flavored standard" signaling protocols and software. At the same time, no telephony platform supports 100% of the features of SIP or H.323.

5.2. Basic Call Handling

Call-handling features are the essential traffic-processing duties of a PBX and the group of applications that most resembles the services available to a POTS subscriber. Connecting, disconnecting, and call transfer are the building blocks of all call-handling applications.

5.2.1. Intercom Call

Intercom calling is the oldest of all telephony applications. In fact, it was the intercom calling application that lead to the invention of the telephone. This one telephony application came even before the network did. When Alexander Graham Bell's assistant heard the inventor 's voice coming through a transducer, quite by accident , the first intercom call was placed.

An intercom call is merely a conversation between two private endpoints. Most intercom calls are two-way conversations, meaning both parties can talk and hear each other talk. In PBX terms, intercom calls are calls between extensions. The setup in Project 4.2 allows you to place intercom calls between the two IP phones.

5.2.2. Mute, Hold, Call Transfer, and Multiparty Conference

Certain features have become more or less staples of a PBX environment. Mute allows the local party to temporarily stop sending sound to the remote party. Hold is a form of mute that allows the local party to leave the phone set for an extended period of time, unattended, and then return to resume the conversation with the remote party. Call transfer allows the local party to hand the call in progress off to another extension, so it can be resumed there. Multiparty conference allows the local party to set up conference calls from her phone.

5.2.2.1 Blind and consultative transfer

A blind call transfer is one in which the transferring party hangs up immediately following the transfer, having no knowledge of the availability of the party to whom the call was transferred. A consultative transfer allows the transferring party to speak with the receiving party prior to making the transfer or merely verify the receiver's availability before completing the transfer.

5.2.2.2 Conference

Multiparty conference , or just conference , allows more than two parties to have a call, all able to hear one another at the same time. With PBXs, these features are accomplished by proprietary programming. In VoIP environments, packet-based signaling systems like SIP and MEGACO (media gateway control protocol) work with DSP (digital signal processing) servers called conference mixers to facilitate this kind of functionality. In the PSTN, SS7 does the job.

5.2.2.3 Meet-me

Meet-me conferences are ad hoc conferences in which users can voluntarily join a conference in progress by dialing a code on their phones. This code can be permanently set in the PBX on behalf of a certain user , or it can be established on the fly by the host of the conference. Users attempting to join the conference may be required to enter a password or PIN code. Not all PBX systems support this kind of conference.

5.2.3. Caller ID

Caller identification , also called calling party identification , allows the recipient of a phone call to know which endpoint is calling both before and after answering. Caller ID signals can be sent using in-band or out-of- band signaling. Some endpoints are able to display the ID information on a built-in display. Some endpoints require an outboard display device. With CTI (computer-telephony integration) programming, caller ID information can be displayed as a part of a PC or web application. SoftPBXs can use caller ID data as criteria for call routing.