Monday, November 8, 2010

Plantronics Savi W430 Review

I have been looking for a great headset to use with Lync 2010 and recently started using the Plantronics Savi W430.
For me, the important qualities to have in a headset:
  • Comfort
  • Sound Quality
  • Travelability
  • Battery Life
  • Ease of Setup

Normally, headsets and I do not get along well. Most of the time after about 10 minutes, my ear is so sore I can't stand it. That is why I've used a corded headset for so long (close to 5 years) even when I had another wireless headset in my laptop bag.

I'm not exagerating when say that I can wear the Savi W430 for a full day and hardly notice that I am wearing it. In fact, the only time I take it off is when I want to, or it needs to be charged.

For me, the smallest foam ear bud was the most comfortable, but the headset came with quite a few options depending on your preference.

Sound Quality

Sound Quality always is fairly high on my list, but it has been quite awhile since I've encountered an audio device that was horrible with sound quality. The Savi W430 is capable of Wideband audio, and there is quite a noticable difference from what I was used to on my old headset. Speech is amazingly clear and crisp for speaking and hearing when making a call.

The other item I noticed when making test calls is that background noise is dramatically reduced. Users no longer hear typing from my keyboard. My normal speaker phone picks up that type of noise up easily.

The background noise reduction is also very handy when working on home. Much of the noise that I used to be concerned with (and constantly muting myself) no longer is heard by the person I am calling.

The Savi W430 is also DECT 6.0 based so I can actually walk upstairs through most of my house and still maintain a converstaion.


I have traveled an average of 50% for 12 years. Any headset that I use, needs to travel.  I've only had the Savi 430 for a couple of weeks, but it seems very durable. The headset comes with a travel bag and charging cord (different from the charging base pictured). Although sufficient, I would have preferred a hard travel case rather than just a little bag to put everything in.

The headset earbud/mic can also rotate so that the headset will lay flat and the ear bud or mic has a less chance to be damaged.

Battery Life

The Savi 430 has a stated Battery Life of up to 6 hours. Although I would prefer more, I'm not sure I would trade the additional talk time for less comfort.

When recharging the headset, the charge time can take as long as 3 hours which is not that impressive.

Ease of Setup

The Savi 430 was a breeze to setup. Lync 2010 automatically detected the headset and it appeared in the audio devices menu without the need to do any configuration or setup.

With Lync 2010, switching between devices is crazy simple now, and switching between this headset and a desktop phone during a call is no different.

I also found the Plantronics Knowledge Base to be the key to understanding how to use the products more advanced features. I could not find an explanation for all the different colors and blinking lights in the documentation that was shipped with the product.

Also, little things like how to mute yourself while on a call was not obvious, but once it is known, it is a very simple process. Here is the link to the knowledge base article I found on the Savi W430.

Plantronics Knowledge Base


Based on the comfort, sound quality and travelability and ease of setup this is the best headset I have used to date. Although the travel bag and charging time could be better,  I would not hesitate to recommend this headset to a customer.

Tuesday, October 12, 2010

Determining which NPA/NXX combinations are Local vs Long Distance

One challenging piece of a OCS / Lync Server Enterprise Voice deployments, in certain areas of the United States, is determining what NPA/NXX (NPA-NXX-xxxx) combinations are local vs long distance.  For example, Dallas can have both local and long distance numbers within the 972 area code. Knowing what combinations are local vs. long distance is essential for creating accurate routing tables.
There are several methods to obtain the local vs long distance NPA/NXX combinations.
  • Trial and error (Everyone's Favorite!)
  • Customer Provided (When it is wrong who will they blame?)
  • Telco Provided (When has a telco been useful?)
  • Voice Partner Provided (Decent chance of getting close, but you may not have one to ask)
  • Local Calling Guide website (Decent chance of getting close and it is a click away)
All of the above sources can have incorrect or incomplete information. However, I've found Local Calling Guide website to be a great starting point to create the routing tables and then use the other sources to fill in any holes, if necessary.

To determine what NPA/NXX combinations are local to your customer go the Local Calling Guide website and click "Search Area Code/Prefix/OCN".

In the "NPA" box enter the customers area code. In the "NXX" box enter the next three digits of the customers phone number (NPA-NXX-xxxx). Then click "Submit"

Information will come up regarding the NPA-NXX you entered. Click the Rate Centre (Dallas in the example above).

Displayed, will be all the NPA/NXX combinations local to the Rate Centre. Although many NXX are displayed, this list can be misleading and missing some entries.

To see the complete list click on See All Local Prefixes.

Not only will the list be complete (or at least what is in the database), the list will also be displayed in a delimited format that can easily be manipulated in a spreadsheet or database.

Thursday, October 7, 2010

Communicator for Mac 2011 Deployment Guide

Found the Deployment Guide for Communicator Mac 2011 today and here are the items that caught my eye in the deployment guide.
  • Calendar based presence
  • Presence in other Office for Mac applications
  • Outlook Out of office messages in Mac Communicator
  • Invite multiple people to conference
  • Join conf: meetings from an outlook Invite
  • Enterprise Voice supported
  • OCS 2007 R2 support (OCS 2007 RTM is not)
Not available
  • Access Level for Contacts
  • Call forwarding
  • Receiving calls on mobile devices
  • Voicemail access from Mac Communicator
  • Scheduling of conferences in Outlook
  • Desktop sharing
  • No mention of Live Meeting
I am extremely pleased with the progress the Mac Communicator team has made. I expect the user experience with Lync to fill in some of the holes above with the Reach client. Finally, the Mac user can join the rest of the Unified Communications fun!
Here is the link to the Mac Communicator Deployment Guide. Enjoy!

Monday, October 4, 2010

Wireshark tips and tricks for VoIP/SIP (Shhhh Don't tell the Feds)

Knowing how to use Wireshark is no longer optional. The ability to see what is happening on the wire to troubleshoot all types of software is absolutely necessary. This is especially true for VoIP and related protocols.
Fortunately, Wireshark does a great job of making this easy.

The Basics

Wireshark is open source and it can be obtained from
Installation is fairly straight forward. Sometimes, first time installers skip the installation for WinPcap, but this piece is required and should not be skipped.

Capturing Network Traffic

Wireshark will capture any network traffic that comes to the network interface of the computer it is installed on. The network traffic at first may not make sense, but with the tips I have below, I hope to help you make sense of what Wireshark captures. 

To start the capture, choose “Interface” under the Capture menu. Then, click Start on the appropriate network interface. As soon as you click start, the captured network traffic will begin to displayed. Depending on how much traffic is on the network interface, thousands of packets can be captured in a very short amount of time.

When you want to stop capturing packets, select "Stop" under the "Interface" menu.


To help with viewing the network traffic we are interested, Wireshark provides ready made filters for different types of traffic. For purposes of this blog post we are interested in "sip" and "rtp". Please note that these filters are case sensitive. Type "sip" into the input field right above the packet capture display and hit Enter or click "Apply". The screen capture below shows the packets have now been filtered for sip only.

Some other filters that may come in handy:
  • ip.addr == (filter on source and destination ip address)
  • ip.dst == (filter only source ip address)
  • ip.src == (filter only destination ip address)
Wireshark Decode As

Some Wireshark protocols do not decode properly by default. From my experience, most of the time this is because they are sent across non-standard ports for that protocol. RTP (media for VoIP) packets are guilty of this quite often.

Right click the offending packet and choose "Decode As". In the dialog box choose the appropriate protocol for the packet. In the example below, the choice would be "RTP".

After the packet has been decoded properly more information will appear about the packet.

In the example below we now can see the RTP stream is encoded G.711.

Viewing Diffserv Code Point (DSCP) in Wireshark

Open "Internet Protocol" section under packet and "Differentiated Services" area. All 8-bits are decoded. The first 6 in the example below decode to be "Expedited Forwarding".

How to decode RTP packets into Audio (Shhh Don't tell the Feds)

Wireshark can reassemble VoIP packets into audio. This technique can be helpful to identify if audio quality issues are caused by the network.

If there is no indication of packet loss in the analyzed packets, and the audio still has problems, then the audio problems were created before the packet was encoded.

To start the process to convert to audio, click on the packet then choose "Stream Analysis" under the "Telephony -> RTP" menu.

Click on the audio stream to be converted to audio, then click "Analyze".

Once the stream is analyzed, click "Save payload". Each side of the audio can be saved independently or together. Choose .au for the audio type. The .au format can be played back in almost any media player including Windows Media Player.

G.729 can be decoded as well. However, since compression is used the audio files have to be run through another decompression program. There are two blogs that cover this, but you can search the internet for others.

Extend your Wireshark knowledge and read another blog post I have that covers how to decrypt packets.

Thursday, September 30, 2010

Cost Savings Calculator for Unified Communications

Microsoft has produced a really well done Cost Savings Calculator for Unified Communications. Although calculators like this are notoriously inaccurate because they make certain assumptions, Microsoft seems to have created a calculator with enough nobs and buttons that would allow a company to make a decent cost savings calculation.
Ultimately, the goal of calculators like this are to start discussions around what changes to communications can mean for a business.
If you click the "About" in the upper right-hand corner of the Calculator it will give you all the formulas Microsoft used for calculations.

OCS / Lync Server Normalization Rule Primer


When normalization rules were first explained to me in an Office Communications Server 2007 training class, I left completely confused.

I spent quite a lot of time trying to understand how normalization rules work. First, I found that normalization rules are .Net Expressions. A quick search of the Internet for .Net Expression primers and help guides did not help with understanding how they worked.

I finally found a piece of software called .NET Regular Express Designer that allowed me to see what is happening in a .Net expression and more importantly a normalization rule.

Let's start with why we need telephone numbers (straight from the IETF/ITU standards).
  1. A telephone number is a string of decimal digits that uniquely indicates the network termination point.
  2. The number contains the information necessary to route the call to the termination point.
A Normalization Rule modifies the user input and presents a fully routable telephone number that can be used by Office Communications Server (OCS) / Lync Server and the PSTN to delivery a voice call to the intended termination point. To OCS / Lync Server, your telephone number is effectively meaningless if it is not presented in E.164 format.

Humans are inconsistent, especially with how we write phone numbers down. People use parens, dashes, dots, and spaces for example. Users in a business might only know a 4 digit extension to call another employee. Normalization Rules help the humans enter the phone number in the format they are used to and then translate that to the pattern that OCS / Lync Server is expecting.
There are three main processes happening when a normalization rule is used.  
  1. Does the Phone Pattern Regular Expression match the input?
  2. What is captured in the Phone Pattern Regular Expression to be used by the Translation Pattern Regular Expression?  
  3. What is the Translated number?

Example Normalization Rule 

Phone Pattern Regular Expression: ^(2\d\d\d)$
Translation Pattern Regular Expression: +1425555$1
The "^" specifies that the match must occur at the beginning of the string.
Anything between parens is captured into a group. If there are more than one set of parens then there are multiple groups.

Any letter that is after "\" is considered a language element and has a special function. For example \d is a single digit wildcard. \D is a single character wild card.
"$" Specifies that the match must occur at the end of the string.
In the above example we are matching against any 4 digit number that starts with a 2. We are capturing the 2 into group 1 plus any other 3 digits that follow. If a number is 5 digits it will not match. If a number starts with any other number than 2 it will not match. 

Now that we have captured group 1 we can take a look at the Translated Pattern Regular Expression
Phone Pattern Regular Expression: ^(2\d\d\d)$
Translation Pattern Regular Expression: +1425555$1
The +1425555 are absolute digits and will be inserted before the captured digits in group 1 "$1". Each group is represented by a $ and a digit for the order in which they were captured. The second group captured would have a "$2" in the Translation Pattern Regular Expression. 
If we entered 2345 then the translated pattern would be +1425552345.

What if we wanted to match against 5 digits and only capture 4 for example?
Phone Pattern Regular Expression: ^6(\d\d\d\d)$
Translation Pattern Regular Expression: +1425555$1
The above rule would match any 5 digit number that started with a 6. But, because the 6 is not within the Parens we will not capture the 6 into group 1.
If we entered 62345 then the translated pattern would be +1425552345.

Is there an easier way to specify multiple digits rather than writing\d\d\d\d?
Phone Pattern Regular Expression: ^6(\d\d\d\d)$
Translation Pattern Regular Expression: +1425555$1 

is the same as
Phone Pattern Regular Expression: ^6(\d{4})$
Translation Pattern Regular Expression: +1425555$1
The {x} specifies the number of matches for the preceding Language Element. In this case we are looking for 4 digits. If I specified \D{4} then it would be 4 characters.
If we entered 62345 then the translated pattern would be +1425552345.

What does a normalization rule look like capturing multiple groups of numbers?
Phone Pattern Regular Expression: ^(\d{3})(\d{4})$
Translation Pattern Regular Expression: +1425$1$2
In the above Phone Pattern there are two sets of parens. Each set of parens captures into a different group. The first three digits are captured into group 1 "$1" and the next 4 digits are captured into group 2 "$2".
In the Translation Pattern we use $1 and $2 after the +1425.
If we entered 5552345 then the translated pattern would be +1425552345.

What if we wanted to handle dashes, spaces, dots, and whatever else users dream up?
Phone Pattern Regular Expression: ^(\d{3})\D(\d{3})\D(\d{4})$
Translation Pattern Regular Expression: +1$1$2$3
In the Phone Pattern Regular Expression we are matching for 3 digits, then a single character. Then another three digits, and a single character. Then a final four digits. Since the \D is not within the parens we match against it, but are not capturing it. The result is the Translation Pattern has no dashes, dots, spaces, or any other character the user can dream up.

If we entered 425-555-2345 or 425.555.2345 then the translated pattern would be +1425552345.

Why do you use \D instead of [\s()\-\./] ? 

Simple. It does the same thing and more! \D will match any non-digit. [\s()\-\./] will only match space, parens, dash or dots.

Is there a way to do optional matches?
Phone Pattern Regular Expression: ^9?(\d{3})\D(\d{3})\D(\d{4})$
Translation Pattern Regular Expression: +1$1$2$3
In the Phone Pattern Regular Expression above we start of with a "9?". This means the expression will match if there is a 9 or not a 9. The key is using the question mark after the number (or character). This is handy if you want to be allow users to still dial a 9 like they used to on a PBX. They can type it in or not, we simply don't care because it is optional and we are not capturing that digit into a group.

If we entered 9425-555-2345 or 425-555-2345 then the translated pattern would be +1425552345. 

How would I do a wild card for any number of characters/digits?
Phone Pattern Regular Expression: ^\D*(\d{3})\D*(\d{3})\D*(\d{4})$
Translation Pattern Regular Expression: +1$1$2$3
The above Phone Pattern Regular Expression will look for any amount of characters until it matches against 3 digits. Then any amount of characters until it matches against another 3 digits. Then a match against the last four digits.
The benefit of this is that we can handle "(425) 555-1234" or "425-555-1234" or "4255551234" and to be honest we can handle this too "Your grandma 425 has white 555 hair 1234". All the examples would be translated to +14255551234

How about logical OR?
Phone Pattern Regular Expression: ^\D*(303|720)\D*(\d{3})\D*(\d{4})$
Translation Pattern Regular Expression: +1$1$2$3
A logical OR is very handy if you need to handle multiple area codes, or NXXs (the second set of 3 digits for non-voice people). The pipe sign is what does the logical OR within the parens. The above Phone Pattern Regular Expression would look to match the first three digits to 303 or 720, but not both.

If we entered 303-555-2345 or (720) 555-2345 then the translated pattern would be either +1303552345 or +17205552345.


In my experience the above examples will help with 90% of the needs for Normalization Rules. There are much more complicated Normalization Rules that could be written, but I'll leave that to another post. If you want to play around with Normalization Rules I strongly encourage downloading .NET Regular Expression Designer so that you can visibly see how Normalization Rules work.

Tuesday, September 28, 2010

Exchange UM Express Messaging

When replacing voice mail systems from from companies like Avaya/Nortel, the customer may expect to have the functionality of Express Messaging. Express Messaging is essentially a number that users can call to leave a voice mail directly in a users mailbox without ringing their phone.

Not only can you replicate this functionality with Exchange UM, you can do it speech enabled so the caller only has to speak a persons name.

How to create speech enabled Express Messaging Auto Attendant in Exchange UM
  1. Use a WAV editor (Audacity works well) and record a greeting for this feature similiar to the following (format should be WAV, 8khz, Mono): Welcome to Exchange UM express messaging, to leave a message for someone , say thier name , or dial their extension"
  2. Create a new Exchange Auto Attendant that is speech enabled.
  3. After the Exchange UM Auto Attendant is created, edit the properties and in the features tab uncheck "Allow callers to transfer to users".
  4. In the features tab check "Allow callers to send messages".
  5. In the features tab uncheck the "Allow transfer to operators".
  6. In the dialing restritions tab check the "Allow calls to users within the same dialing plan".
  7. In the dialing restrictions tab check "Allow calls to extenstions".
  8. In the greetings tab assign the recording you made in step 1

Friday, September 24, 2010

Enable Save Password for Office Communicator

Not all users sign in to their PCs with Domain credentials. For those that sign in to a local user on their PC it is a nuissance to enter your username and password every time you sign in to Office Communicator
I found a regkey that enables the Save Password checkbox under the Password field.
SavePassword created as REG_DWORD and the value should be 1
Next time you sign in, check the box and from then on it works just like you are signed in with Domain credentials.

New Communicator for Mac

Posted on the Mactopia blog is news that there will be a separate client for OCS/Lync on the Mac that is different than the Mac client for Messenger.

The new client is called Communicator for Mac.

Although there is no mention of Enterprise Voice or Live Meeting support, I think this is a step in the right direction toward having a fully functional Mac client for the OCS/Lync.

One encouraging quote is:

On the Messenger team, that overall mission translates into helping people communicate and collaborate to get their work done using Microsoft Office. One focus of Office for Mac 2011 was to integrate real-time communication features into Office applications like Word and PowerPoint and we expect that effort to continue.

One other quick note is that the new client will be available only to volume licensing customers only.