Resolution: The burnflash utility is used to manually update the switch with the current version firmware compatible with the ShoreWare server software.

When you install a new switch, ShoreTel’s TMS service is set up to detect the switch’s firmware version and automatically upgrade your hardware to the latest version.  For instances that require manual firmware upgrade, you could use Burnflash utility to manually upgrade switch firmware.  Please refer to Maintenance Guide for detail instruction.

A reliable, affordable and secure, fax-over-IP? You are probably thinking to yourself, “No way!”. Here at EtherSpeak we say, Yes way! EtherFax is the answer.

With respect to voice over IP, a codec is an algorithm used to encode and decode the voice conversation. Since voice and sound as we hear it is analogue, it needs to be converted (or encoded) to a digital format suitable for transmission over the Internet. Once at the other end, it needs to be decoded again so the other person can hear what you are saying. There are a variety of different ways this encoding and decoding can be done – many of which utilise compression in order to reduce the required bandwidth of the conversation. A key thing to remember with VoIP, is that encoding, particularly when heavy compression is used, takes time, which adds a delay to the conversation. Thus, the holy grail is a codec which not only maintains good quality with compression, but is able to do the encoding and decoding in a minimal amount of time.

These pages attempt to demistify codecs and give a brief overview of the different codecs and when they are used. It is important to keep in mind that different VoIP clients support different codecs, and each VoIP provider will only support a subset of the codecs too. Generally, when a VoIP call is established, you will need to use a codec that both parties and the provider support. No need to worry though, this sort of negotiation is handled automatically, but knowing the details will enable you to force or encourage certain codecs to be used. Understanding codecs will also help you understand why some VoIP clients sound better than others, and why voice quality with some providers, or through certain ISPs, are better than others.

If you would like to read up more about codecs with respect to VoIP, the following links may be of interest:

• Codecs page the VoIP Wiki
• Find out which hardware supports which codecs.

Codec Comparison

The following table lists the various codecs used in voice over IP, and in particular SIP. Many codecs come in a few varieties, and we have attempted to list all such version of each codec. If you would like to voice your opinion about a particular codec, or discuss the merits of one over another, feel free to do so in our voice over IP forums.

Notes

The information provided here is for information purposes only, if you find errors or ommissions, please report them in the relevant discussion forum.

Bandwidth

• Bandwidth values represent the amount of data in the payload of the IP packets.
• Bandwidth values indicate the bandwidth in each direction – not the sum of upstream and downstream bandwidths.
• Bandwidth values assume continuous transmission of voice in both direction with no silence suppression.
• The ‘nominal bandwidth’ column indicates the typical Ethernet bandwidth one can expect the codec to use.

Sampling Rate

The sampling rate is the rate at which the analogue audio signal is sampled. Nyquist’s Theorem states that in order to record a certain frequency, sampling must occur at at least twice that frequency. Thus, the higher the sampling rate, the greater the frequency range in the encoded audio stream. The human ear is capable of hearing from about 20Hz to about 20,000Hz. Typically, speech is around 100-4,000Hz. Thus, a sampling rate of at least 8kHz is required to accurately encode the human voice. Greater sampling rates will capture higher frequencies (this is useful, for example, if you are playing music down the phone), but will also increase bandwidth as there are more samples to encode and transmit.

Payload Size

The size of the payload of each encoded voice packet influences two things: lag and bandwidth. Every encoded packet that is sent incurs fixed bandwidth overheads (due to IP and other headers added to the data in the network). Thus, larger payloads incur a proportionately smaller overhead, thus reducing the nominal bandwidth utilisation. However, by using larger payloads, more audio (ie., a longer period of time) is required to construct a single packet, which in turn increases the amount of time it takes for even the beginning of the packet to reach the other end and be decoded, thus increasing the lag in the conversation. This is a typical trade-off in VoIP. Most codecs use payload sizes of 10-40ms.

When making a call over the Internet, the software (soft-phone) or hardware needs to use a codec to send/receive information in a certain format and convert it to the sounds you hear.

SIP Interoperability – Why Is It So Hard to Achieve? (Part I)

Posted by Alan Percy, Audiocodes | Jun 8, 2009

For those of you that have deployed SIP-based solutions or SIP Trunking, there is a pretty good chance that you’ve had to navigate your way through the maze of SIP interoperability, wondering why it is so difficult to get a straight answer out of anyone on whether two systems will work together or not.

SIP is supposed to be a standard and eliminate many of the challenges with integrating systems from various vendors together, right? If my IP-PBX is RFC 3261 compliant and my SIP Trunking service provider is RFC 3261 compliant, they should just work, correct? Well–maybe or maybe not. Most likely there will be interoperability issues.

Today I thought it would be good to start a multi-part series of posts to explore why SIP interoperability seems to be as challenging as it appears, how the vendors are dealing with it and solutions you can use to solve difficult interoperability challenges.

The Root Cause
Let’s start with a discussion on the root causes that make SIP interoperability difficult. The problem starts not with technology, but with the way that IETF Requests For Comments (RFCs) are developed. As opposed to the old ITU specifications that the Telecommunications Industry has lived with for the last four decades, IETF RFCs and Drafts are developed in an open and communal environment, using committees and consensus to craft the specification. This has very many positive benefits, but also a few predictable negative side effects. The problem is that RFC 3261 that defines SIP has become “everything to everyone” and bloated in both size and in flexibility.

Performing a simple word count on RFC 3261 yields some interesting insight into the problem:

Weak Terms
May = 381
Should = 344
Option = 144
Can = 475

Strong Terms
Shall = 4
Must = 631

As you can see, the number of weak terms “May,” “Should,” “Option” and “Can” outnumber the stronger “Shall” and “Must,” which results in a very loose specification that allows the developers of SIP-based systems to make plenty of decisions on features of functions. The byproduct of this is that two systems can be completely RFC 3261 compliant and completely incompatible.

Examples
In our experience, there are no fewer than five “correct” ways to transport DTMF tones from one end point to another:

* In-band–leaves the DTMF tones in the RTP streams
* RFC 2833–uses specialized payload packets in the RTP stream to indicate a DTMF tone
* SIP NOTIFY–uses a SIP message to indicate the presence of a DTMF key press
* SIP INFO (Nortel)–a technique frequently used in Nortel systems that uses a SIP INFO message
* SIP INFO (Cisco)–a variation on the above, but with some slight modifications.

Another example that is causing a lot of grief right now whether to transport the SIP messages over UDP or TCP. The RFC indicates that either is okay and recommends supporting both, but few manufacturers actually do support both. The vast majority of equipment and application developers chose SIP-over-UDP. Microsoft chose SIP-over-TCP. Again, both are within specification and completely incompatible.

While these technical challenges may seem difficult to overcome, they can be solved. However, the political issues are another story.

SIP Interoperability: Why Is It So Hard to Achieve? (Part II)

Posted by Alan Percy, Audiocodes | Jun 15, 2009

Earlier this week I shared with you a few thoughts on SIP Interoperability, discussing what I felt where the root causes of incompatibility between two or more SIP-based systems. I clearly hit a raw nerve with a few of you, flooding my email box with your own stories of interoperability issues. You shared with me your own experiences with registration problems, call transfers, security, message waiting indications, even fax issues. It seems the couple examples I gave were only the tip of the iceberg.

Let’s move past the technical issues with SIP Interoperability and talk about a far more difficult challenge–the politics of SIP Interoperability.

It appears to me that soon after the authors of RFC 3261 finished their work, the fun really started. As the development teams of the various product and application companies started to build their solutions based on RFC 3261, the looseness of the specification allowed them to make wildly different choices all “within specification.” The result was that you had developers that had invested untold hours of hard work into developing a protocol stack that worked fine in their own lab and with their own products, but had serious interoperability issues with other vendors. To each of the developers, it appeared that “everybody else screwed up.”

So now you have a number of overworked developers that would have to go back into their products and re-work significant parts of their SIP stacks–just because someone else made some bad choices. The end result is a classic standoff with each of the vendors saying “we followed the spec, you should change.” So much for “Open and Standard.”

To make things even more politically complex, many of the vendors are starting to compete in the marketplace, vying for the same markets and customers. In this competitive environment, interoperability is a double-edge sword.

Okay, so let’s pretend our developers get past their own stubbornness and decide to make some changes to be more interoperable. Who do you do your interoperability testing with? Do you test against anyone that comes along? Or maybe just in cases where “the business case works?” What happens if you or anyone else makes changes? Do you re-test with everyone? It was easy when there were just a few other applications to test with on the market, but now with hundreds of applications and devices to test, it becomes clear that the maintenance of SIP interoperability testing becomes a bigger burden than the original development.

FOR IMMEDIATE RELEASE                                                                          

         .

DENNISON TECHNOLOGY GROUP PURCHASES IDEACOM MID-AMERICA SHORETEL DIVISION

Dennison Technology Group announced Friday that it has purchased Ideacom Mid-America’s ShoreTel services division.  Under the terms of the agreement, Dennison Technology Group purchased ShoreTel telecommunication assets, customer base and assumed certain liabilities of Ideacom Mid-America for an undisclosed purchase price.

This transaction expands Dennison Technology Group’s client base of ShoreTel VoIP clients in Minnesota, Illinois and Wisconsin.  Dennison Technology Group, in partnership with Ideacom, will now be able to provide a comprehensive collection of integration applications designed to enhance the communications of small- to medium-sized businesses.  Dennison Technology Group has remained in the top of all dealers in the U.S. for its world-class customer satisfaction rating.  For additional information, or to learn more about Dennison Technology Group, please visit www.dennisontech.com <http://www.dennisontech.com/>.

About Dennison Technology Group

Dennison Technology Group is a VOIP systems integrator with a unique offering, one that looks at an entire organization and how communications are managed — internally, with suppliers, prospects and perhaps most importantly, with customers.  Our analysis is focused on inspecting a business and its major cost centers.  Our goal is to find areas of opportunity to help increase revenue, reduce costs and increase productivity.

“We are excited for the opportunity to expand our territory and customer base,” said Troy Brevig, president.  “This is a clear message that Dennison Technology Group is dedicated to the ShoreTel product and expansion into new markets.  The alliance with Ideacom Mid-America will benefit Dennison Technology group’s customer base with expertise in systems integration, application development and direct support for customers in Wisconsin and Illinois.”

About ShoreTel

ShoreTel, Inc., (NASDAQ: SHOR) is a leading provider of Pure IP unified communications systems.  The ShoreTel IP phone system is a completely integrated system that scales seamlessly from 1 to 10,000 users including PBX, voice mail and automated attendant functions.  The ShoreTel system is built from the ground up and designed to be the easiest to use, easiest to manage, full-featured IP phone system on the market today.  Its distributed architecture is ideal for multi-site companies that span multiple locations because the ShoreTel IP phone system appears and behaves as a single, unified system.  ShoreTel enables companies of any size to seamlessly integrate all communications – voice, data, messaging – with their business processes.

About Ideacom Mid-America

Ideacom Mid-America is a major converged communications systems provider specializing in integrated Business System for Healthcare communications.  Ideacom and CMA offer complete systems support, from consultation services to installation and on-going systems support for acute care, long-term care and assisted living healthcare facilities.

“Many new doors have opened for Ideacom” said Myron Anderson, CFO of Ideacom Mid-America.  “This transaction allows us to focus on our industry leading healthcare communication services and has added a large base of customers who have needs beyond basic integrations.”