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.

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!

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 http://www.wireshark.org/.

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.

Filtering

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 == 47.148.254.140 (filter on source and destination ip address)
• ip.dst == 47.148.254.140 (filter only source ip address)
• ip.src == 47.148.254.140 (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.

http://wiki.wireshark.org/HowToDecodeG729

http://wiki.wireshark.org/RTP_statistics

Extend your Wireshark knowledge and read another blog post I have that covers how to decrypt packets.
http://blog.lyncdialog.com/2013/11/using-wireshark-to-decrypt-lync.html