- Asterisk 1.6
- Barrie Dempster, David Gomillion, David Merel
- 3404字
- 2021-04-01 14:03:36
Terminal equipment
Now that we have decided on our PSTN interconnection, we need to decide on our internal connections. Our PBX can have modems, fax machines, hardware and software telephones, and other PBXs connected. We will refer to all these different machines as terminal equipment.
Types of terminal devices
There are four major types of terminal equipment—hard phones, soft phones, analog adapters, and PBXs. We will cover each type briefly.
The term hard in hard phones is the short form of hardware. Hardware phones are physical devices that act as a telephone handset. Hard phones are available for POTS (as used in the typical household) or VoIP. Hard phones will typically deliver the highest quality among types of terminal equipment. The most popular hard phones in the market today are:
Voice over IP uses various protocols depending on the handset, PBX, and the requirements. The major protocols supported by Asterisk are as follows.
The first protocol we will be looking at is H.323. Formally known as ITU-T Recommendation H.323, Packet-based multimedia communications systems, this is a suggestion on how to accomplish conferencing over IP, which includes voice, video, and data. This recommendation actually came at about the same time as SIP but has been more widely implemented.
The H.323 standard enjoys full backward compatibility. Currently H.323v5 is out, and v6 is being discussed. Each new release keeps all the pieces of the previous version. This gives a clear upgrade path and some assurance that the equipment won't be quickly antiquated.
H.323 equipment is widely available. From gateways to telephone handsets, all of the needed equipment is relatively easy to find. Most of the telephone handsets are full-featured because the H.323 protocol has a robust feature set.
While the H.323 standard was not designed for wide area networks, a whole set of rules allowing cross-domain addressing have been created. A system for reporting Quality of Service (QoS) back to a server has also been developed, allowing such information to be used to route future calls.
Finally, H.323 as a standard supports call intrusion. New endpoints can be added dynamically to any conference (that is, a call) at any time.
Asterisk support for H.323 is not built in. Instead, an additional package, asterisk-oh323, must be installed. After installation, H.323 handsets and gateways can be addressed much like any other channel in Asterisk.
The Session Initiation Protocol (SIP), is another method of signaling VoIP calls. SIP is a part of the default installation of Asterisk.
Most of the new VoIP equipment supports SIP. SIP has a number of advantages. One such advantage is that the code is smaller. The reason for this is that SIP only supports very basic features. All advanced features are supported through separate Internet standards. Another reason for its small footprint is that, as features are deprecated, the code to implement them is ousted.
Another advantage of SIP's design is its modular nature. As such, extending the protocol is easier to do. It also scales better and was designed with a large network in mind.
SIP seems to be the future of VoIP. There are many features that H.323 has, but are not available on SIP. This includes handset conference control, better Media Gateway definitions, and data sharing. However, SIP is a very good protocol for simple phone calls. Also, as we are using Asterisk, conferences are controlled by Asterisk, not the handsets. Asterisk is a clear Media Gateway, and when used as such, the ambiguity in SIP is not an issue.
The Inter-Asterisk eXchange (IAX) protocol is a protocol created by the programmers who brought us Asterisk. Due to the limitations of SIP and H.323, they chose to create a new de facto standard that would allow Asterisk servers to accomplish many things that are simply impossible with the other standards. They also support some features that are extremely difficult to do in SIP and H.323.
First, IAX pierces Network Address Translation (NAT) easily. Most firewalls and home Internet gateways use NAT, as well as some service providers. SIP and H.323 have worked hard to develop standards to allow them to break through the different types of NAT. However, IAX can work through most NAT devices right out of the box.
IAX is more configurable than the other protocols when dealing with Asterisk. As the source code is available, we can modify it if we so desire, and then submit those changes to be evaluated for inclusion in future versions of Asterisk. As IAX is not currently an Internet standard per se, there is no standard body to work through, allowing more rapid improvement and growth.
IAX supports the trunking of calls. This means that multiple calls can be combined through a single stream. Through the trunking capability, a significant amount of bandwidth can be saved by not having the overhead of multiple streams.
IAX connections between servers support the switch command with which information on how a call is routed can be efficiently shared between Asterisk servers.
IAX supports a large number of codecs. Any codec supported in Asterisk can be used with channels of this type.
As IAX is an Asterisk-created protocol, there are not many handsets and gateways available. However, as time passes, more and more devices are supporting the IAX protocol.
Just as a note, we sometimes see IAX and IAX2 differentiated. IAX2 has been merged into IAX, and IAX has been deprecated. Thus, if a device claims to support IAX2, it should really be supporting IAX.
Much as hard phones are phones implemented in hardware, soft phones are phones implemented in software. Using all the same protocols available to hard phones, soft phones are far less expensive to implement. By using the general-purpose computing resources of a personal computer, the expensive proposition of replacing all telephones in a building can be avoided.
Before going further, we should recognize that most hard phones are in reality soft phones combined with bit of special-purpose hardware. The computing power of a hard phone is not as vast as that of a PC, and unlike a PC, is specially tuned for carrying voice. Thus, we should not dismiss the use of hard phones immediately.
The sound quality experienced on a soft phone will depend greatly on the available resources on the PC, the quality of the software used, and the quality of the data network between the PC and our Asterisk server.
Soft phones will have a hard time being accepted by some users. In addition to the political issue of having people use their computer to talk on the phone, we also have to address disaster planning. If we lose power, keeping a computer up that draws in excess of 400 watts will be far more difficult and costly than keeping power to a hard phone that draws 15 watts, especially for prolonged outages.
The most significant advantage of the soft phone is cost and portability. In most businesses, desks contain a computer and phone at least. If you can remove the phone there is an obvious reduction in hardware costs. There are a variety of soft phone products available and most operating systems come with a basic soft phone package by default. Also the portability aspect of a softphone can be very appealing to companies that have employees who travel a lot. Imagine you're staying in a hotel that offers high speed access. Simply open your laptop, put on your headset, and you're able to make as well as receive calls as if you were in the office. There are also a variety of open source products available. Some companies such as Counterpath (www.counterpath.com) and Zoiper (www.zoiper.com) offer free clients for Windows, Linux, and Mac.
If you decide to go with a softphone also be sure to invest in a decent headset with noise cancellation. Headsets that have their own DSP and are USB driven are a good choice. This removes most audio processing resources from the PC so that other work done on the PC does not affect voice quality. The choice of product, soft or hard, is equally important as the PBX. You must be sure that the users will use the device and be sure that it will be reliable and supportable.
Dedicated communication devices such as modems and fax machines are still very prevalent in business today. Although these devices could be replaced with more modern, reliable, and faster technologies, the new technologies have not yet been embraced.
Therefore, in order to use these existing technologies, analog adapters allow companies to continue using legacy devices such as traditional fax machines. An analog adapter usually consists of an Ethernet jack with which the device will connect to your network and an FXS port (telephone jack) which will connect to your traditional communication device (such as a fax machine).
Another common use of an analog adapter is to connect a cordless phone for those requiring mobility around the office. Granted there are WIFI SIP phones in the market, often users will find that the WIFI signals interfere with other frequency emitting devices. Such interference can cause distortion or the calls to drop.
One issue with analog adapters is their use with traditional fax machines. For years the reliability of faxing over an adapter was poor at best. Today analog adapters are becoming equipped with T.38 capability. This protocol allows regular faxes to be sent over UDP. The use of T.38 dramatically improves the reliability of faxing. However, keep in mind—your VSP as well as your PBX must also support T.38 in order for the fax to be transmitted using this protocol. As of version 1.4, Asterisk now supports T.38 negotiation for SIP users and the related pass through of UDPTL T.38 data. Please note that Asterisk currently cannot terminate T.38 calls or act as a T.38 PSTN gateway without external support.
One extra note about faxing—Asterisk supports receiving and sending faxes through an add-on called SpanDSP. With this Asterisk can receive a fax and turn it into a TIFF file. This TIFF file can then be further processed to become a PostScript or PDF file and be emailed to the proper recipient. Another notable fax detection solution is NVFaxDetect. The installation of this add-on is not covered here, as it is changing rapidly.
These communication devices are usually supported for legacy reasons. We should continually strive to reduce outdated technologies and replace them with up-to-date solutions.
We can connect PBXs together to provide services to users hosted on another PBX. We can use SIP, PRI, T1, H.323, or IAX to connect the PBXs.
If we are connecting multiple Asterisk PBXs, we should use IAX. The IAX protocol has a number of features with this specific use in mind, such as the ability to have multiple conversations trunked into the same UDP stream yielding greater efficiency.
Choosing a device
Now that we have seen the broad offerings of terminal devices, we will see how difficult it can be to choose one to meet our needs. After choosing a type of device, we have to choose a manufacturer and model. This task can be daunting. Let's take a few minutes and discuss how we will make the best decision based on the available information.
As we review available phone handsets, we will be inundated with all the features that manufacturers can throw at us. These lists are overwhelming, even to the most seasoned experts. It is very difficult to compare two handsets solely on features, as some features have different names.
Determining the usability of a particular phone handset should be a straightforward process. This process has four major steps—requirement elicitation, prioritization, and documentation, followed by handset testing.
This is the brainstorming step. We should go to each user and determine what his or her needs are. We ask the user what features he or she uses on the current phone. We observe the person working for a period of time to get a good sampling of what he or she actually does.
We should then go to the user's manager and see what a person in that position is expected to do. We add these features to our list. While this list will be unique to each user, many will be very similar. We should see patterns of usage emerge between groups of employees.
In this step, we take our requirements list from the previous step and, working with the user and manager, determine which features are used most, which are most important to that user's role in the organization, and which features are simply nice to have. We should also attempt to recognize any deficiencies in the current technology. Changes are often embraced if the change adds value to the user by making a task easier or in some cases removing a task entirely. It's important that we recognize all nuances of the current system in order to provide the user with a replacement that will suit them.
We should then create a quantitative scale for each feature. For example, if we were working with an operator, a Transfer button would be a value of 10, while a Do Not Disturb button will probably be a value of 1. If we had a phone handset with both of these abilities, then we add these scores together and it would score an 11. By putting numbers on the required features, we can come up with a quantitative answer to a very subjective issue.
This step is the most important of all of the steps so far, especially for consultants. We take the list of requirements and their weights, and write them in a short document. We then have the user and the manager sign it to indicate their agreement.
This may seem a little formal for picking a telephone handset, but it is an effective method of communicating expectations and plans between you, the implementer, and the users. This can help in preventing surprises or differing recollections of what was promised.
This is the final step. After comparing the available handsets against the document we created in the previous step, we choose the highest scoring handset. We then take a handset of that type to the user and have him or her use it (if we have a test system installed by this point) or at least sign off on it conceptually.
Again, this is an opportunity to ensure our users' expectations are reasonable, that commitments are clearly defined, and that our users are kept informed during the decision-making process. It can also help us get a buy-in from the users as we make the major adjustments that will invariably accompany a new phone system.
When we look at which handsets to compare our requirements document with, the issue of cost also will have to be looked at. Before we offer a handset that would not be possible under our project budget, we should determine that the handset meets all of the requirements of the business, which includes the element of cost.
The issue of cost is not as simple as looking at the retail price of a handset. Each type of phone will have multiple types of cost. These costs will usually fall into one of the following categories:
- Handset cost: This is the easiest cost to determine. It is the actual amount of money that will have to be spent to acquire the telephone.
- Port cost: This cost is the element of what the phone connects to on the other end. For instance, on a VoIP phone this could be a portion of the cost of a new network switch that supports Quality of Service (QoS) to enable reliable voice communications.
- Headset cost: If a phone will require a headset, then we should consider the cost of that headset as we choose the phone. Different connectors are available depending on the model.
- Software license cost: Some phones will require the purchase of G.729 license. Other phones may require a license for the software on the phone (usually referred to as firmware). We should not fail to consider this cost while computing the cost of the phone.
- Installation cost: The time required to install different phones differs. This time translates into cost.
By considering each of these factors for each different handset, we get an idea about the true cost of each particular phone. With all of these costs defined, we can see which phones are within our budget and which are simply too expensive.
Not all handsets interoperate equally with Asterisk. Referring to the Asterisk Users Mailing List archive, we can ensure that no serious incompatibilities have been discovered. Also, a Wiki is available at http://www.voip-info.org. A vast array of useful information about Asterisk is available there. This site is searchable and is constantly updated.
We do not have to select a single protocol for all VoIP phones. Instead, we can mix and match protocols to our best advantage, thanks to the flexibility and power of Asterisk.
Sound quality is a very subjective thing. Each user will have a personal threshold between acceptable and unacceptable.
Each phone will have a varying sound quality. The variables that can affect the quality of a call are staggering. Network latency can significantly affect sound quality, but so can configurations of the phone. Determining what the cause of low sound quality is can be difficult to do.
Build quality from a manufacturer can also affect quality. When wide variations are allowed from one phone to the next, the result is usually inconsistent from handset to handset. Thus, we have to choose a manufacturer we can trust.
While there is no absolute, the quality of sound on telephone handsets, from highest to lowest, is usually as follows—analog hard phone, VoIP hard phone, analog soft phone, VoIP soft phone. If you are doing a comparison between different handsets, the main things to pay attention to are the amount of background noise (or hiss), distortion, drop outs, popping, and highly digitized voice. If we have users who are extremely sensitive to sound quality, analog will probably be our best bet. For those users who are a little more forgiving, VoIP allows us to use one network for our phones and computers.
When determining what terminal equipment to use, we need to consider the sound quality of each device and match it against the needs and expectations of our users, and weigh that with the cost of that device as compared to the budget.
The world's most advanced VoIP handset is absolutely useless if our users cannot figure out how to use it. As we decide what equipment to provide for our users, we should consider where they are at in the continuum of technological awareness. While VoIP hard phones with context-sensitive buttons are useful for most users, some people find the interface confusing and frustrating.
This is one big issue that we need to address in the handset testing that we do after eliciting the requirements that our user has for a new phone. We have a duty to ensure that our users can use the handsets we choose. We must be careful not to assume that they will figure it out, as doing so often causes hurt feelings and resistance to change. The success of Asterisk will be largely measured by the response of our users.
Recording decisions
It is time to decide what kinds of terminal equipment we will use with Asterisk. First, we should make a list of all users of our phone system. Based on the requirements we get from them and their supervisors, we should decide what type of device to use, whether it is a hard phone or a soft phone. Next, we should determine a protocol to use. Finally, determine a brand and a model of phone to use.
We should take the time to write this down. This list should be provided to the decision makers, and kept up-to-date as changes occur, which they inevitably will. Again, doing so will keep everybody informed and rein in the expectations to keep them reasonable.