Everything Voice

Setup IP SLA Jitter Monitors

2010-04-21T20:03:00.007-04:00

IP SLA is a feature that is built into the Cisco IOS that allows you to generate continuous traffic in a predictive continuous manner to measure network performance.
The way it works is that the software sends out a probe to measure round trip times of various protocols/applications on your network.

IP SLA can monitor measure several types of network services including:

FTP
HTTP
DHCP
DNS
TCP Connect
UDP Jitter
VoIP UDP Jitter
UDP Echo
ICMP Echo

Since its inception, IP SLA has been referred to as RTR, SAA and now SLA. As such, syntax will vary from different IOS releases as you will see in the following example.

Here is the topology I'm using:

I will be monitoring jitter from my 3640 to my 2610 router. With the following example, you will see the difference in syntax as well as the results of the probe. In this topology, I have full IP connectivity from end-to-end and it is actually the simulated WAN for my VoIP lab.

To start, I'll first configure the 2610 to be the SLA responder. I'm using IOS version 12.3(25) so the commands to configure this are:

R1(config)#rtr responder

That's it. Pretty simple. Now, I'll configure the jitter monitor on my 3640 running IOS version 12.4(15):

CME1(config)#ip sla monitor 10
CME1(config-sla-monitor)#type jitter dest-ipaddr 10.1.2.2 dest-port 5000 codec g729a advantage-factor 0
CME1(config-sla-monitor-jitter)#tos 184
CME1(config-sla-monitor-jitter)#frequency 60
CME1(config-sla-monitor-jitter)#exit
CME1(config)#

The first line creates the monitor. 10 is kind of like a "session" number that can be referred to when you have multiple SLA monitors running, or by various other commands.
The second line specifies the type of monitor.  For this example, jitter. 10.1.2.2 is the destination address which is the SLA responder, and 5000 is a port I selected from random. The codec specified is g729a. By specifying a codec, the results will generate MOS and ICPIF scores. The advantage factor is a handicap that would account for normal degradation of communications and is required even if the value is zero.
The third line sets the TOS bit to Diffserv decimal 184 which is Expedited Forwarding (EF).
The forth line specifies the frequency of the monitor.

To enable IP SLA, I'll begin the schedule:

CME1(config)#ip sla monitor schedule 10 start-time now life forever

To confirm our configuration, we would type this:

CME1#sh ip sla mon conf

SA Agent, Infrastructure Engine-II
Entry number: 10
Owner:
Tag:
Type of operation to perform: jitter
Target address: 10.1.2.2
Source address: 0.0.0.0
Target port: 5000
Source port: 0
Operation timeout (milliseconds): 5000
Codec Type: g729a
Codec Number Of Packets: 1000
Codec Packet Size: 32
Codec Interval (milliseconds): 20
Advantage Factor: 0
Type Of Service parameters: 0xB8
Verify data: No
Vrf Name:
Control Packets: enabled
Operation frequency (seconds): 60
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Enhanced History:
Now that it's started, let's see what kind of output we get:

CME1#sh ip sla monitor statistics 10

Round trip time (RTT) Index 10
            Latest RTT: 56 ms
Latest operation start time: *07:18:21.703 UTC Sun Apr 21 2002
Latest operation return code: OK
RTT Values
            Number Of RTT: 1000
            RTT Min/Avg/Max: 55/56/65 ms
Latency one-way time milliseconds
            Number of one-way Samples: 0
            Source to Destination one way Min/Avg/Max: 0/0/0 ms
            Destination to Source one way Min/Avg/Max: 0/0/0 ms
Jitter time milliseconds
            Number of Jitter Samples: 999
            Source to Destination Jitter Min/Avg/Max: 1/1/9 ms
            Destination to Source Jitter Min/Avg/Max: 1/1/7 ms
Packet Loss Values
            Loss Source to Destination: 0 Loss Destination to Source: 0
            Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0
Voice Score Values
            Calculated Planning Impairment Factor (ICPIF): 11
MOS score: 4.06
Number of successes: 1
Number of failures: 0
Operation time to live: Forever

As you can see, there is information about the round trip time (RTT), latency and jitter. You can also see the packet loss data including tail drop, and of course, my favorite...the MOS score of this packet...very cool stuff! To make more sense of this data, there are also a number of commercial and free network monitoring tools that you can use to monitor and graph IP SLA statistics. Some free tools include Cacti and MRTG.

This is a very simplistic example of the power of IP SLA. Scouring the internet, I've found that it can also be used to inject a default route into IGPs, policy route failover and so much more using the 'track' keyword within those configurations and referring to the IP SLA "session" number configured earlier.

There are two (IMO) particular caveats to the IP SLA configuration. First and most evident is the different syntax for different IOSs. Second, you can't directly edit the IP SLA configuration. To do so, you must first remove the IP SLA (ie. no ip sla monitor 10), then recreate it to make changes.

Here is an excellent Cisco IP SLA configuration guide for IOS 12.4:
http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/slah_bk.pdf
Just remember, some of the commands may differ with your version of IOS.

Converting a Cisco 7940/7960 from SIP to SCCP

2010-04-19T20:08:00.001-04:00

I just received two IP phones that I won off eBay today. When I fired them up, I found they both had SIP software installed. No biggie. So I fired up my CallManager server and installed the latest SCCP software (8.1.2) and registered the phones.

Now, I proceeded to reset the phones to factory default settings. The procedure to do this on the 7940/60 is pretty simple:

1. Power on the phone while holding the pound (#) key. The Headset, Speaker, and Mute buttons will begin to flash in sequence, and you will see "Reset key sequence detected" displayed on the LCD screen.
2. Enter 123456789*0# on the phone.
3. You will then be prompted to keep your network configuration. Press 2 for No. This will force the phone to reset its network configuration.

Now, this worked great for my 7960 but not for my 7940. The 7960 loaded the SCCP software, but the 7940 showed me that it wanted to load image P00308010200 which was correct, but at the end of the boot sequence, it still loaded with the SIP software.

After a ton of Googling and trying a whole bunch of stuff, I came across a post that suggested perhaps I was trying to upgrade to firmware that was "too recent". I then installed SCCP firmware 7.2.3 and BINGO, the SCCP firmware loaded.

My take on this is that you can only upgrade to a "more recent" SCCP image from a certain version of SIP, and unfortunately, I didn't record which version of SIP these two phones were running. I found a Cisco page that suggested this, but did not present the resolution that I ended up taking to make this work.

Gotta love how much you can learn in 3 hours!

Sniffing and Eavesdropping using Wireshark

2010-04-18T15:10:00.034-04:00

Many VoIP users probably don't realize that their calls can be monitored and listened to using free tools available on the internet. Although it is very easy to do, the eavesdropper is required to be on the same broadcast domain, or must be in the path of the RTP stream.

To be on the same broadcast domain, the eavesdropper could plug into a hub that inter-connects the CallManager and the phones. A hub broadcasts ALL traffic out to ALL ports thus allowing the RTP stream to be visible. Fortunately in today's modern networks, hubs are no longer used.

To be in the path of the RTP stream, the eavesdropper would have to 'tap' into the stream directly by using a SPAN port on the switch that's configured to monitor the ports of one or both of the endpoints (IP phones). Setting up SPAN to monitor the CallManager port will not show any RTP streams because once the call is negotiated, the RTP stream in not handled by the CallManager, but rather by the two endpoints.

Cisco provides a good configuration example of SPAN here: http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a008015c612.shtml

In this blog, I will demontrate how SCCP and RTP packets and be monitored, examined and I'll even show you how to playback an RTP stream. For this, I will be using Wireshark.

A note about Wireshark
Wireshark is a powerful tool that no network admin should be without. I strongly encourage anyone serious in networking to take some time a play with this application. It can really be helpful to diagnose and troubleshoot network issues. There are a myriad of functions and settings that no blog can completely cover. Wireshark Network Analysis is a 3lb. monster of a book to help you with that.

Before I begin, I first have to setup a SPAN session on my Catalyst 2950 switch to monitor ports Fa0/2 and Fa0/3. On these ports, I have two Cisco IP phones which I will initiate a call between. Doing it this way, I'll get both sides of the conversation. On port Fa0/7, I have a PC running Wireshark.

Here are the commands to create a SPAN session:

ALS1(config)#monitor session 1 source interface fa0/2 , fa0/3 both
ALS1(config)#monitor session 1 destination interface fa0/7

Now, I can verify my SPAN session:

ALS1#sh monitor session 1

Session 1
----------
Type : Local Session
Source Ports :
Both : Fa0/2-3
Destination Ports : Fa0/7
Encapsulation : Native
Ingress: Disabled

Now I will start a live Wireshark capture and place a call between my 2 IP phones.

The first thing you see is the Skinny protocol in action:

The moment I answer the call, the RTP stream begins as shown here:

After a short conversation with myself (yes, that is possible!), I hang up and end the live capture. Now, to see only the RTP stream, I add a filter by typing 'rtp' in the filter box and click on 'Apply':

Scrolling through and analyzing some of these packets, you'll notice that there is a wealth of information. You can see the codec I'm using (default G.711), and the QoS markings on the packets. I must be doing something right, as my packets are DSCP 0x2e which converts to decimal 46 which is EF (Expedited Forwarding).

I now clear the filter, and apply a filter for skinny packets as shown below:

Notice my SCCP packets are marked with DSCP 0x1a which translates to decimal 26 which is AF31.

Now for the fun part, playing back an RTP stream.
From the Wireshark menu, click on the Telephony menu item and select 'Show all Streams':

Select one of the 2 streams and click the 'Analyze' button:

From the RTP Stream Analysis screen, click the 'Save Payload' button:

Type a filename, choose the save location and select 'au' as the file format and click 'Save':

Navigate to the file, double-click and you should hear 1 half of the conversation. To get the other half, save the other stream.

You can listen to both parts of the conversation using Wireshark's built-in player as follows. From the main Wireshark menu, select, Telephony and select VoIP Calls:

Select the streams you want to play and press the 'Player' button:

On the RTP Player window press the 'Decode' button and you'll see a graphic representation of the voice. Now select the checkbox for both streams:

Now, just press Play, and you'll hear both sides of the captured conversation.

As you have seen, eavesdropping on a VoIP call is not very difficult to do. It can be easily mitigated by locking down access to switches and rogue SPAN ports and/or implementing encryption such as SRTP or IPSec.

Configuring Cisco CallManager - Part 4: Class of Service

2010-04-17T16:00:00.000-04:00

In this blog, I'll describe how to configure Class of Service (CoS) to implement calling restrictions. I will be using the line/device approach of CoS where the entire dial plan will be assigned to the device (IP Phone) and the restrictions will be placed on the Directory Numbers (DNs).

When a Calling Search Space (CSS) is configured on both the device and line, CCM concatenates the two CSSs and places the line CSS in front of the device CSS. The result is that the restrictions are processed first and if a match is found, the call is blocked an no further processing is required. If no restriction matches are found, the call is routed to the dial plan.
If two identical route patterns are in each the device CSS and the line CSS, the pattern in the line CSS is processed first.

Here is a diagram that simplifies this concept:

To implement this, you first create 5 partitions:

Then you create 5 CSSs and assign the partitions to it. The SITE_CSS will be assigned to each device, and the other partitions will be assigned to the line of device based on the access you define. The order of the partitions in the CSSs matters as they are processed top down.

SITE_CSS = PSTN_PT
INTERNAL_CSS = BLOCK_900_PT,BLOCK_LOCAL_PT, BLOCK_LD_PT, BLOCK_INTL_PT
LOCAL_CSS = BLOCK_900_PT, BLOCK_LD_PT, BLOCK_INTL_PT
LD_CSS=BLOCK_900_PT, BLOCK_INTL_PT
INTL_CSS=BLOCK_900_PT

As you can see, applying these CSSs to the line of a device will give you more granular control of what a particular DN can dial. INTERNAL_CSS being the most restrictive, and INTL_PT being the least restrictive.

Before we can create router patterns, we must first create a Route Group and a Route List. (Moving forward, I have a Cisco 3640 acting as my PSTN gateway. This was setup in Part 3)

My route group contains my PSTN gateway. I named the route group "TO PSTN":

Next, I created my route list which includes the route group I just created and named it "TO_PSTN":

Now you can create your route patterns. You will have two route pattern entries for each route pattern. One that will be assigned to the PSTN_PT, and the other will be assigned to it's appropriate BLOCK PT. (9.911 and 911 are exceptions with only one entry since we never want to block outgoing calls to emergency services.):

For the route patterns assigned to the PSTN_PT, make sure the option "Route this pattern" is selected (which it is by default). Also, be sure to select the appropriate route list:

For the patterns assigned to the BLOCK partitions, be sure the option "Block this pattern" is selected and select the "Call Rejected". Also, be sure to selet the appropriate route list:

Now we are ready to test our Class of Service.

First, we configure our device (phone) CSS to the site CSS as highlighted below. (In my case, the site CSS name is EAST1A_CSS):

At this point, I can dial pretty much anything (ie. internal, local, long distance and international). This is because the Site CSS has the PSTN_PT assigned to it. There are no restrictions on the PSTN_PT partition.

To add restrictions, we assign a CSS to directory numbers (DNs) based on the type of access we want for that DN. Below, DN 2009 is assigned to the Internal CSS:

With this assignment, DN 2009 can only call 911 and internal numbers. Any local, long distance and international numbers will result in a busy signal.

To assign unrestricted access to any number, you would assign this DN to the international CSS.

Configuring Cisco CallManager - Part 3: Configuring IP Phones and Gateways

2010-04-17T15:46:00.004-04:00

Now here's the fun part. Configuring IP phone and voice gateways.

Adding a phone is a pretty simple process. From Call Manager Administration, click on 'Device' and select 'Phone'

From the 'Find and List Phones' click 'Add a New Phone'. In my case, I'm adding a 7960 that I just won from an eBay auction.

Clicking 'Next', you are now presented with the Phone Configuration screen. The 3 mandatory fields that youneed to worry about here are the MAC address, the Device Pool and the Phone Button Template as highlighted below:

Now click on Insert. You will then be prompted with the following:

You can choose to skip this step and configure the directory number of the phone at a later time. I'll choose to setup the line number now by clicking 'OK'.

Now you're presented with the Directory Number Configuration screen. All you need to do here is enter the Extension of Line 1. I've assigned it extension 2010 as highlighted below:

Click the Add button, and you now have an IP phone and DN registered with CallManager. If you haven't already done so, start up the IP phone and you'll see it register with the CallManager server and it will have a DN assigned to Line 1.

Now that we've worked through a basic phone setup, we'll proceed to configure a voice gateway. In this example, I have a 3640 that I'll use as a PSTN gateway.

From Call Manager Administration, click 'Device' then click on 'Gateway':

Click 'Add a New Gateway'. In this example, I'll be setting up an H.323 gateway rather than an MGCP gateway:

Clicking 'Next' brings me to Gateway Configuration window. For the Device Name, enter the IP address of the Gateway. Select the Device Pool that the Gateway will belong to and click Insert. You will be presented with a dialog to remind you to reset the gateway. Click on the Reset Gateway button then click on Reset.

I now have a Gateway registered with CallManager. There is no configuration to do on the router to complete the H.323 configuration.

Configuring Cisco CallManager - Part 2: CCM System Configuration

2010-02-14T19:48:00.000-05:00

We'll first take a look at the System menu:

Note: You'll notice that we will be configuring items from the top of the menu to the bottom. This is nice and I believe it's like that by design. You'll see the same thing as we dig into the other menu items.

There are plenty of options to be set from here. I'll touch on only those I usually configure in my initial setup. I would recommend that you peruse each menu item to become familiar with them.

Cisco CallManager Group Configuration
A Cisco CallManager group specifies a prioritized list of up to three CCMs. The first CCM in the list serves as the primary CCM for that group, and the other members of the group serve as secondary and tertiary (backup) CCMs.
I generally create a geographic group and assign my lonely CCM to it. As you add more servers, it is then an easy task to add them to a group.

Date/Time Group Configuration

This feature allows you to define and assign different time zones for devices on your network. Here I defined my current time zone, which I will later assign to my devices:

Region
This feature lets you define the bandwidth to be used within a region and between regions. As you define more regions, you will see that you can specify codecs and bandwidth to be used between them. The default codec used is G.711. If you don't intend on using any other codec, then there is no need to use regions. But if you are providing VoIP over a WAN, chances are you need to use a more efficient codec, and that's where regions come in. Initially, I don't set up regions until I get the WAN part of my topology in place.

Device Pool Configuration
A device pool is used to define sets of common characteristics for devices. Setting this up right the first time around goes a long way later. In this example, I set up a device pool called 'LAB PHONES' that will later be used to group all the phones together.

Enterprise Parameters
I think of this as the 'registry' of CCM. Worth a look to get familiarized. The option I like to turn on is "Enable Dependency Records":

This option allows you to check dependencies of objects. Say you want to delete a partition and that partition is assigned to multiple CSSs. You can now click the check dependencies link and it would list all the CSSs that the partition is associated with.

Real world note: Cisco says that turning this option on chews up CPU cycles. Now, I'm not so sure that having the option enabled causes an excessive load on the CPU, but I'm sure it does when you actually use it.

Location
Locations are used to implement CAC in a centralized call-processing model. You can regulate audio quality and video availability by limiting the amount of bandwidth that is available for audio and video calls over links between the locations.
Again, not too worried about CAC just yet until I need to worry about running out of bandwidth.

SRST
I posted in another blog how to configure this, but for the initial setup of a standalone CCM server, it's premature to set this up until I get my gateway(s) in place.

Now that we've configured the basics of CCM, we're finally ready to configure dial plans and phones.

Configuring Cisco CallManager - Part 1: Setting up a DHCP Server

2010-02-14T19:43:00.000-05:00

When I first got my mitts on Cisco CallManager, the first thing I wanted to do is get 2 phones to be able to ring each other. I realized that there was a bit of configuration to do with CallManager before you even begin to register IP phones. I'll outline the steps I take to configure a fresh CallManager install in a lab scenario.

For the purpose of this blog, I'm using Cisco CallManager 4.1(3) which is natively installed on Windows 2000 Server.

The first thing I do is configure a DHCP server to assign IP address information to the IP phones. In a lab environment, I don't normally have a DHCP server running, so I set it up on the CallManager server itself. In the real world, you will generally already have a DHCP server setup and you can configure it to hand out IP address information.

Nothing special here, define a scope, specify an IP address range, define standard scope options such as DNS and Router (default gateway) and activate the scope. Now, Cisco IP phones expect the DHCP server to provide the IP address of a TFTP server to obtain its configuration files. This is done by configuring one of 2 options: Option 066 or Option 150.

Note: Option 150 is preferred and both options are mutually exclusive. From what I gather, Option 066 can only have one name or dotted decimal entry whereas Option 150 can have multiple or redundant TFTP servers. Here is a link that explains some of this: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/3_1_2/ccmsys/a02tftp.html

In Windows DHCP, Option 150 has to be manually added. You do this by right-clicking on the server selecting 'Set Predefined Options...'

From here you create Option 150 as shown:

Now that Option 150 is created, add it to your scope options... DHCP is ready to go.

At this point, I like to check that CallManager's TFTP service is started. To do this, go to 'Cisco CallManager Serviceability' and select 'Service Activation' from the 'Tools' menu.

Now let's get under the hood of this thing called CallManager.

Cisco Translation Rule Tester

2009-12-14T14:46:00.005-05:00

Came across this link in my google searches: http://www.redsack.com/blogs/translation.aspx

This is an online voice translation rule tester that comes in pretty handy if you're not in front of a router to test the output of a translation rule. Enjoy!

Configuring Cisco SRST

2009-12-07T19:59:00.008-05:00

Survivable Remote Site Telephony (SRST) is a great feature included in Cisco voice gateways that provides redundant call control for remote branch offices. In the event of a link failure (typically WAN), IP phones can register with the SRST gateway and process calls with the absence of the CallManager.

Here is the topology that I'm using to demonstrate the configuration and functionality. (Please refer to the left side of the topology with CCM41 East1A and the 3640 router).

Here is a list of the equipment I'm using in this part of the topology:

Cisco 3640 IOS 12.4(7) with CME
Cisco CallManager 4.1
Cisco 7912 IP Phone

The first thing I did was configure the 3640 router with the following commands:

CME1(config)#call-manager-fallback
CME1(config-cm-fallback)#ip source-address 10.10.20.254
CME1(config-cm-fallback)#max-ephones 15
CME1(config-cm-fallback)#max-dn 40

The call-manager-fallback command enables the SRST
The ip source-address command is the IP address that IP phones use as their default gateway, or the address configured in Call Manager as the SRST reference. (Typically, it's the IP address of the voice gateways ethernet interface).
The max-ephones 15 command specifies the maximum amount of IP phones allowed to register with the SRST router.
The max-dn 40 command specifies the maximum amount of directory numbers (DNs) allowed to register with the SRST router.

Note: The number of devices and DNs that can register to the SRST router is platform and IOS software specific. They should be based on the number of SRST client licenses you have purchased. Please refer to http://www.cisco.com/ for the latest SRST platform and IOS software support.

Now that the router is configured for SRST, we'll configure the CallManager

If the SRST router is the default gateway of the IP phones, continue to the next step. Otherwise, create an SRST reference from the System -> SRST menu to define an SRST Reference. Here is what mine looks like:

Either create a new Device Pool or select an existing one.
Scroll down to the SRST Reference dropdown. Select either Default Gateway or the SRST reference you created:

That's it in a nutshell for the configuration part. Now if you break the link to CallManager, you can watch the phones failover to the SRST router as the message "CM Fallback Service." will appear on the LCD display.

If you would like to customize the failover message displayed on the IP phones, use the following command on the SRST router:

CME1(config)#call-manager-fallback
CME1(config-cm-fallback)#system message ?
primary for IP phones supporting static text messages (e.g. 7960 and 7940)
secondary for IP phones with limited display space (e.g. 7910)

Below are some general troubleshooting tips:

To verify that the SRST feature is running on the router, use the following commands:
show call-manager-fallback
show call-manager-fallback all

If your IP phones are not falling back to the SRST router after a link failure, check the phone's Call Manager configuration under Settings -> Device Configuration -> Call Manager Configuration. You should see an SRST entry showing the IP address of the SRST router.

Check to see if the IP phones are in the correct device pool configured for SRST.

When the failed link is restored, I've personally noticed that it takes quite a bit of time for the phones to re-register with the Call Manager server. This is apparently normal and my guess is to avoid unnecesssary network traffic caused by flapping WAN links.

If you plan on pursuing your CCVP, I strongly recommend you know how to configure SRST, if you know what I mean ;o)

Configuring a T1 PRI with a Cisco 3640 and an Atlas 550

2009-12-03T21:32:00.005-05:00

The Adtran Atlas 550 is a neat unit. It allows you to simulate a PSTN cloud by adding various modules and setting up dialplans. My unit consists of an Octal FXS module, an octal FXO module and a T1/PRI Network Interface Module.
Today I'm going to focus on configuring a T1 PRI on the Atlas 550 and a Cisco 3640.

This is the topology that I'm working with:

Here is what you need:

3640
1x NM-HDV module with some PVDM-12 modules (I have 4)
1x VWIC-1MFT-T1 module
1x NM-1V or NM-2V network module
1x VIC-2FXS
1x Analog Handset

Adtran Atlas 550
1x OCTAL FXS 1200309L1
1x T1/PRI Network Interface Module
2x Analog Handsets
1x RJ-48c crossover cable

Here is the pinout for the RJ-48c crossover cable. You can probably pick one up on eBay, but I chose to make mine:

Now, we can configure the T1 PRI module in the Atlas. First make sure that the module is online:

Next, we configure the framing for ESF and line code to be B8ZS as shown:

Next, we configure a dial plan. From the main menu, scroll down to Dial Plan, select User Term. Arrow over to the right and hit the I key to insert a dial plan. Scroll to the Slot/Svc column, hit Enter and select the T1/PRI card. Right arrow to the Port/PEP column and do the same. Scroll to the In#Accept column and press Enter. For this example, I entered 1-416-555-XXXX. This procedure was repeated to insert an entry for (our simulated) 911. This tells the Atlas to accept call to/from 911 and 1-416-555-XXXX over the T1/PRI.

From there, arrow over to the [+] symbol under Ifce Config for the T1/PRI-1 module. Here you will set the specific configuration for the interface:

NOTE: The Called Digits Transfered is set to Four. The reason behind this is that in the real world, a telco will typically pass along only the last 4 digits of the DID. So if someone were to dial 1-416-555-1234, only 1234 will get passed on to the router.

Setting up the FXS ports are just as easy. In the User Term screen, press I to insert a dial plan, but this time, select the FSX-8 for the Slot/Svc column, and select the appropriate FSX port in the Port/PEP column. For the In#Accept column, hit Enter and type in the exact phone number under the Accept Number column. In this example, 1-416-555-1111:

Repeat the same procedure to add an entry for calls to our simulated 911.
Now that the Atlas is configured, let's setup the 3640.
First, set up the ISDN switch type:

   CME1(config)#isdn switch-type primary-ni

To find out your controller number, issue the following show command:
   CME1#sh controllers t1
   T1 3/0 is down.
   <--output omitted-->

Now that you have the controller number, you can configure it:
    CME1(config)#controller T1 3/0
    CME1(config-controller)# framing esf
    CME1(config-controller)# fdl both
    CME1(config-controller)# linecode b8zs
    CME1(config-controller)# cablelength short 133
    CME1(config-controller)# pri-group timeslots 1-24

At this point, you will have seen your controller come up and your channels go down as well. To confirm your controller is up, run show controllers t1:

    CME1#sh controllers t1
    T1 3/0 is up.
    <--output omitted ->

Now configure the serial interface:
    CME1(config)#interface Serial3/0:23
    CME1(config-if)# no ip address
    CME1(config-if)# encapsulation hdlc
    CME1(config-if)# isdn switch-type primary-ni
    CME1(config-if)# isdn incoming-voice voice
    CME1(config-if)# no fair-queue
    CME1(config-if)# no cdp enable

Now you can run sh isdn status to verify Layer 1 and Layer 2 connectivity:

CME1#sh isdn status
    Global ISDN Switchtype = primary-ni
    ISDN Serial3/0:23 interface
            dsl 0, interface ISDN Switchtype = primary-ni
        Layer 1 Status:
            ACTIVE
        Layer 2 Status:
            TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
        Layer 3 Status:
            0 Active Layer 3 Call(s)
        Active dsl 0 CCBs = 0
        The Free Channel Mask: 0x807FFFFF
        Number of L2 Discards = 0, L2 Session ID = 1
        Total Allocated ISDN CCBs = 0

Now, we add some dial-peers:

dial-peer voice 911 pots
description 911 outbound via PRI
destination-pattern 911
port 3/0:23
forward-digits 3

dial-peer voice 11 pots
description LD 11 Digit via PRI
destination-pattern 91[2-9].........
port 3/0:23
prefix 1

dial-peer voice 5001 pots
description Local 5001 Extension of FXS card
destination-pattern 5001
port 2/0/0

dial-peer voice 5 pots
Any call from the PRI matching 5001
incoming called-number 5001
direct-inward-dial

Now we can make some test calls from Ext 5001 to 914165551111 and to 911. To make calls the other way around, simply setup another dial peer on the Atlas (ie. 1-905-788-XXXX). This will allow you to dial 919057885001 from either set on the Atlas to ring Ext 5001 on the 3640.

To view voice calls as they are taking place, use any of the following commands:

sh voice call summary
sh isdn active
sh isdn service

Truthfully, I initially bought the Adtran Atlas just to play around with the T1/PRI. We were implementing this at work and when I saw it in action, I just knew I had to pursue the CCVP. Problem at that time was, I was in the middle of my CCNP. Have to learn to walk before you can run.

My Voice Lab

2009-11-30T22:09:00.006-05:00

Here is my current voice lab topology. It certainly doesn't look as pretty in real life, but it serves my purpose. At the moment, I'm starting to get a bit bored with it though. It's been awhile since I've touched some of the basics of how I configured it, so I thought over the next little while, I'd pick apart the configurations and blog them to help renew my interest. Nothing like hearing the phones ring when it all works well!

The servers depicted here are actually one server running VMware images and each have their own physical NIC. The Asterisk part of it is the newest edition to the topology.

Current things I'd like to get working are:

SIP trunk between Asterisk and CCM. I spent a day trying set this up. What a frustrating day that was. Needless to say that I didn't get it working, but I've got some tricks up my sleeve yet.
Throwing CME into the mix somewhere. Believe it or not, I've never really configured CME. During my CCVP studies, everything focused on CCM and I never got around to it, despite having CME on my 3640.

OK then. Along with the above two tasks and blogging about the configurations of the lab, that should keep me busy for a bit. Bear with me as I'm told I can have a long short attention span so I'll cover something well, then move on to something else before I get too bored.

Configuring Cisco ATA-186 with Asterisk

2009-11-24T22:09:00.009-05:00

The Cisco ATA is a sweet little device. They come in 2 flavors: The ATA-186 and ATA-188. The difference between the two is that the ATA-188 has an internal Ethernet switch. They can run either SCCP or SIP voice protocols making them very flexible.
Another note of importance is that they do not support two ports running the G.729 codec simultaneously. If one port is using G.729, the other will use G.711.

Now that we have a little technical background on these units, let’s see how I made them work with Asterisk.

I decided to do configure and upgrade the firmware all in one shot via TFTP. The ATA firmware I'm upgrading to is SIP 3.2.1.
To obtain firmware, you need a Cisco CCO account, or some good Googling skills. (Fortunately, I have access to the firmware through work). Now, just for the record, the following procedure is not mine. It is well posted on the web and I’m including them here for completeness, and to point out issues I encountered when putting them into practice.

---------------------------------------------
Extract the zip archive to a temporary location:

mkdir ata186-3.2.0
cd ata186-3.2.0
unzip ../ata_03_02_01_sip_050616_a.zip
cd ..

The Cisco ATA186 requires a binary configuration file. The tool to create a binary file from a text file has been provided by Cisco. Create a temporary location for the text configuration files. I like this to be a subdirectory of /tftpboot.

mkdir /tftpboot/ata186_txt

Copy the firmware image to /tftpboot and the configuration files to /tftpboot/ata186_txt. Change permissions on cfgfmt.linux to make it executable.

cp ata186-3.1.1/ATA030200SIP041111A.zup /tftpboot
cp ata186-3.1.1/cfgfmt.linux /tftpboot/ata186_txt
cp ata186-3.1.1/ptag.dat /tftpboot/ata186_txt
cp ata186-3.1.1/sip_example.txt /tftpboot/ata186_txt/atacommon.txt
chmod 755 /tftpboot/ata186_txt/cfgfmt.linux

Create a phone specific file, such as /tftpboot/ata186_txt/atamacaddress.txt where ‘macaddress’ is replaced with the MAC address of the ATA device. (Note that the MAC address for the ATA186 needs to be lower case).

For example create /tftpboot/ata186_txt/ata0006d7a576d0.txt:

#txt
include:atacommon.txt

# Configuration information
TftpURL:192.168.77.4
NTPIP:192.168.77.4
upgradecode:3,0x301,0x0400,0x0200,192.168.77.4,69,0x050116a,ATA030201SIP050616A.zup

# Our asterisk server
Proxy:192.168.77.4
SIPRegOn:1

# line appearances
UID0:201
PWD0:test
UID1:202
PWD1:test

# Make G.711u the default codec
RxCodec:2
TxCodec:2

# Turn off G.711 silence suppression (VAD)
AudioMode:0×00140014

Finally create the binary configuration file for the specific ATA186 by running the cfgfmt.linux tool:

cd /tftpboot/ata186_txt
./cfgfmt.linux -sip ata0006d7a576d0.txt ../ata0006d7a576d0
---------------------------------------------

Now, this procedure works flawlessly if done correctly. The only issue I had was with the upgradecode command, specifically, the image_id field shown bolded below:

upgradecode:3,0x301,0x0400,0x0200,192.168.77.4,69,0x050616a,ATA030201SIP050616A.zup

Cisco states clearly in their instructions to use the build date of the image file for this value and prepend with 0x. Now, make sure that any letters are in lowercase or your ATA will never upgrade it’s firmware. So in my case, the image_id is: 0x050116a

Now I was ready to try out my newly configured ATA. After configuring 2 extensions on Asterisk, I powered on the ATA, and the firmware updated correctly and the unit was commissioned as per the configuration files.

Note: To verify the upgrade was successful, you can either login to the web GUI or use 123# on the IVR to verify the new firmware has been loaded.

Now when I dialed out using the ATA, I got a busy signal. It can never be that easy right? So how do I troubleshoot a box that seemingly appears to only have a web interface to work with?

Along with the firmware image, there’s a neat debug tool called prserv which they provide for different platforms. I decided to use the Windows version which I ran from a notebook connected to the same subnet.

Now, I logged into the ATA web GUI and set the following parameter:

NPrintF which is located under ‘Debug Parameters’. The value I used was port 9001 of the IP address of the host that prserv was running. The correct format is:

192.168.250.119.9001

The important thing to note here is that the port number is separated by a period (.) not a colon (:) as one might expect.

Once you save the configuration, you’ll get real-time debug information from the ATA.

Now, back to my problem. It turns out the debug was pointed me to a codec issue. I was getting '401 Unauthorized' in my registration responses on the ATA when dialing out. To add further pain, I was getting a '488 Not Acceptable Here' message on my softphones when dialing out.

Ok, taking a step back, I recall messing around with codecs awhile back to get the SIP trunk to my service provider working with Digium’s G.729 codec. To do this, I added the following lines to my sip_general_custom.conf:

<…lines omitted>
disallow=all
allow=g729

This worked great, but little did I know at the time that these lone entries broke my softphones and was preventing my ATA from working. Why? Well, recall that we set the default codec to be G.711u in the ATA’s configuration file. And as for the softphones, X-Lite doesn't support G.729. This is when I figured out what the hell was going on. I was only allowing G.729 through in my Asterisk configuration!

An easy fix. Now, my sip_general_custom.conf looks like this:

<…lines omitted>
disallow=all
allow=g729
allow=alaw
allow=ulaw

Amazing how things work much better when you configure them correctly.

QoS on the Catalyst 2950

2009-11-17T22:23:00.010-05:00

Cisco can be somewhat annoying when it comes to the differences in their Catalyst switching platfoms. One of the first things you find out in the QoS course is that QoS configurations differ from Catalyst switch series. And to top that off, the 2950 comes in 2 flavors...Standard image and Enhanced image. The type of image is determined by the hardware, not the IOS.
The two can be likened to a pigeon and an eagle. They can both fly, but the eagle is much more beautiful to watch.

Where I'm going with all this is that I've got my Asterisk server setup with a trunk to a SIP provider and some Polycom phones on the inside. Dialing in both directions work so I figure I'd start deploying QoS working my way from the LAN out to the WAN.
After some heavy Googling, I found out that Asterisk marks voice packet with a DSCP of 5 and signalling traffic with a DSCP of 3. Fine and dandy.

On the 2950 EI, I'd setup the interface as follows:

interface FastEthernet0/1

description Asterisk Server
switchport access vlan 100
switchport mode access
mls qos trust dscp
auto qos voip trust
spanning-tree portfast

This allows the DSCP markings to pass through the switch unscathed and the router can do it's trick to queue traffic out to the WAN.

On the 2950 SI switch, there is NO mls qos trust dscp command, only mls qos trust cos. Leaving it like this, I notice that the router isn't matching any voice or signalling packets. On the router, I'm using a match ip dscp ef in the class map to match. When I run show policy-map int s0/0, the counters for the voice and signalling classes are not increasing as they once did! What the hell? Isn't EF equivalent to CoS of 46? What is this SI switch doing?
Turns out the switch is doing exactly what I told it to (go figure), trusting the CoS value, but it's re-writing the DSCP value from 46 to 40. Why?
Because here is the default CoS-DSCP mapping for the 2950:

CoS Value	0	1	2	3	4	5	6	7
DSCP Value	0	8	16	24	32	40	48	56

CoS of 5 gets the DSCP value re-marked as 40 which is no longer EF, now it's CS5. And on the SI image, you can't seem to modify this mapping like you can on the EI image, so I ended up configuring the port as follows:

interface FastEthernet0/1

description Asterisk Server
switchport access vlan 100
switchport mode access
mls qos trust cos pass-through dscp
spanning-tree portfast

The pass-through dscp keyword allows the interface to trust the CoS value and not modify (pass-through) the DSCP value.

Now I know I could have run my switch without any QoS commands and all would work well. (I tried this). That would spark the old debate that QoS is not really needed on a LAN as much as a WAN. Lots of bandwidth, why waste your time? End-to-end QoS is industry best practice and besides, what else would I do for fun?

Configuring a Polycom IP 430 Phone with Asterisk

2009-11-16T21:58:00.004-05:00

Just for the record, I'm using AsteriskNOW 1.5.0 (32-bit). This release of Asterisk included a web GUI to configure just about everything. Being a Cisco and Microsoft guy, I've had very little Linux exposure so this was a bit of a learning curve for me. Nonetheless, armed with some basic Linux commands, I managed.

The first thing you need to do is to download the latest Polycom SIP Software. Be sure to read the footnotes and view the release documents as there are 2 flavors of download...combined and split. Use the 'split' download if your phone is running BootROM SIP Release 4.0.0 or newer and 'combined' for BootROM SIP older than 4.0.0.

The only file I really cared about in the download was the sip.ld file. Copy this file to the /tftpboot directory. This directory is the root of the asterisk TFTP server and it's where the phones look for their config files.

I've included a template of the configuration files needed to make this work. Here is a link to my Polycom Soundpoint IP 430 Configuration Files template. You will need to edit the following files:

_phone_extension_.cfg file:
This file defines the Lines on your phone.
Rename this file to the extension number you would like to use for this phone. In this example, I'll use extension 2003. So I'll name the file x2003.cfg. You will need to edit the contents to match your configuration. Here is an excerpt I used for Line 1 on this phone:

reg.1.displayName="Matthew"
reg.1.address="2003"
reg.1.label="2003"
reg.1.type="private"
reg.1.thirdPartyName=""
reg.1.auth.userId="2003"
reg.1.auth.password="password"
reg.1.server.1.address="192.168.250.100"
reg.1.server.1.port=""
reg.1.server.1.transport="UDPOnly"
reg.1.server.1.expires=""
reg.1.server.1.register=""
reg.1.server.1.retryTimeout=""
reg.1.server.1.expires.lineSeize=""
reg.1.acd-login-logout="0"
reg.1.acd-agent-available="0"
reg.1.ringType="2"
reg.1.lineKeys="1"
reg.1.callsPerLineKey=""

_mac_address_.cfg file:
This file defines the boot order of your phone.
Rename this file to match the MAC address of the phone it will be applied to. The naming convention of this file is phone_mac_address.cfg and make sure that all letters are lowercase (ie. 0004f214ed16.cfg).
Edit this file. Change the entry "_phone_extension_.cfg" to the file we edited and saved earlier (x2003.cfg).

server.cfg file:
This file defines your asterisk server configuration. Edit this file to match your configuration. Here is an excerpt of my file:

voIpProt.server.1.address="192.168.250.100"
voIpProt.server.1.port="5060"
voIpProt.server.1.transport="UDPOnly"
voIpProt.server.1.expires="3600"
voIpProt.server.1.register="1"
voIpProt.server.1.retryTimeOut="0"
voIpProt.server.1.retryMaxCount="0"
voIpProt.server.1.expires.lineSeize="0"

(Remember, for each phone you add, you must create a new mac_address.cfg and extension configuration file. The other files do not need any modifications).

Now copy mac_address.cfg, x2003.cfg, phone1.cfg, server.cfg, sip.cfg and sip.ld all to the /tftpboot directory.

Now we need to setup the Polycom phone to retrieve it's configuration from the TFTP server. On the Polycom phone, select:

Menu -> Settings -> Advanced -> 456
Admin Settings -> Network Configuration
DHCPClient: Set to Enabled

DHCP Menu:
• Timeout - 3
• Boot Server – Custom+Opt.66
• BootSrv Opt – 128
• BootSrv Type – IP Address
• VLAN Disc – Disabled
• VLAN Disc Opt. - 129

Be sure to save the settings and the phone should reboot with the proper configuration file and extension 2003.

If your phone does not come up with the proper extension, it's likely it has an old configuration. The easiest way I've found to 'reset' this phone is to format the file system. From the Polycom phone, select:

Menu -> Settings -> Advanced -> 456
Admin Settings -> Reset to Default -> Format File System -> Yes

The phone will reboot, reload the application and apply the proper configuration.

Configuring a DHCP Server For Asterisk

2009-11-16T20:12:00.009-05:00

These instructions assume that you have internet access and name resolution within CentOS.

The first thing you need to do is to edit the /etc/dhcpd.conf file with your favorite editor (I used vim) and add the following entries:

ddns-update-style interim;

ignore client-updates;

DHCPARGS=eth0;

subnet 192.168.250.0 netmask 255.255.255.0 {

option routers 192.168.250.40; #YOUR Default Gateway
option subnet-mask 255.255.255.0;
option domain-name "home.local";

option domain-name-servers 4.2.2.2; #DNS Server

option tftp-server-name “192.168.250.100”; #IP Phone Boot Server address

option time-offset -18000; #EST
option ntp-servers 136.159.2.9; #U of Calgary Time Server
option netbios-name-servers 192.168.250.2; #WINS Server

range dynamic-bootp 192.168.250.101 192.168.250.199; #DHCP Range

default-lease-time 43200;

max-lease-time 86400;

}

To start the DHCP service, issue the following command:
/etc/init.d/dhcpd start

To make the dhcp server restart at boot time, issue the commands:chkconfig --level 2345 dhcpd on
chkconfig --level 016 dhcpd off

Then check to make sure it is correct with the command:
chkconfig --list dhcpd

the output should be:
dhcpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

If you are using a software firewall like iptables, you will need to allow all tcp and udp traffic into ports 67 and 68 into this machine.

Next, I'll show you how to configure the Polycom IP 430 to retrieve it's configuration from the TFTP server.

The Gear

2009-11-16T19:12:00.002-05:00

I'm sure this would be every bloggers favorite thing to write about. I've been at the Cisco certifications for 2+ years and have accumulated a lot of networking gear, or as my wife calls it, "toys".
Here's a list of the equipment I'm currently using for my VoIP studies.

3x Cisco 1710
1x ASA 5505 (Base License)
1x Cisco Catalyst 2950 EI
1x Cisco Catalyst 2950
2x Cisco 3650
2x Cisco 2610 w/ 2x WIC-1T
1x Cisco 2613 w/ 1x WIC-1T, 1x NM-1E
1x Cisco 2610 w/ 1xNM-4A/S
1x Cisco 3640 (CME) w/ 1x NM-HDV, 1x 1MFT-T1, 1x NM2E-2W, 1x VIC-2FXS
1x Cisco VG-200 w/ 1x VIC-2FXS, 1x VIC-2FXO
1x Adtran Atlas 550 w/ 1x Octal FXS, 1x Octal FXO, 1x T1 Network Module
1x Cisco 7912, 1x Cisco 7940
2x Polycom IP Soundpoint 430
1x Cisco 2511 Access Server
2x Laptop computers (HP N1020V, IBM T42)
1x Dell Poweredge 2950 running VMWare ESXi with 4 Ethernet cards running the following images:

2x CCM4.1 Servers
1x Unity Server
AsteriskNOW Server

Geez, maybe I do have too many "toys"!

The Blog...Why?

2009-11-16T19:01:00.003-05:00

I've been toying with the idea about blogging for awhile. I've read countless blogs on every networking subject. While some are excellent, others leave a little to be desired. I guess I'm entering this like everyone else thinking "How can I make mine different?". Although I'm not quite sure how to answer that just yet, I figure it will be a work in progress and hopefully evolve to become something cool that I will be proud of.
The blog for me, will be a reference of lab configurations, a place where I can put forth ideas, and perhaps an opportunity to network with my fellow peers.