Friday, September 27, 2013

IOS Codec Preferences

The topic of codec selection comes up regularly in the VoIP provider world. Specifically, concerns regarding customers that have ‘hard coded’ their codec to G729 to the point they won’t allow G711. This explains how codecs get assigned to call legs in Cisco IOS.

You can set up a codec class as described below.

voice class codec 100
codec preference 1 g729r8
codec preference 2 g711ulaw

That works just as you would expect: G729 is the top preference, if that’s not available revert to G711.

Now, you apply that to a voip dial peer:

dial-peer voice 150 voip
destination-pattern .T
session protocol sipv2
session target ipv4:
voice-class codec 100

I personally have another dial-peer set up for outbound fax. For that, I “hard code” to G711, like this:

dial-peer voice 160 voip
destination-pattern *.T
translation-profile outgoing fax
session protocol sipv2
session target ipv4:
codec g711ulaw

Interestingly enough – if you specify no codec for a dial-peer – IT WILL DEFAULT TO G729 AND NOT ALLOW G711. Net, you get the hard-coded G729 scenario if you do nothing to your dial peer.

Cisco IOS Voice Translation Rules

There’s a ton of documentation/examples out there on the interweb about how to use IOS voice translation rules so I’m not going to try to repeat them. Instead, I’ll show one interesting use-case that took me a bit to figure out.

So, the scenario here is implementation of seven-digit dialing for the local area code. I want to append “719” to any seven-digit out dialed number. For ten-digit out dialed numbers, I want to leave them as is.

Here’s how to do it, building up from the basics:

rule 1 /\(..........\)/ /\1/

Rule 1 is ‘matching’ on any ten-digit number, keeping all the matched digits, then copying them all to the replacement number. That solves the “leave them as is” problem with ten digit dialing.

rule 2 /\(.......\)/ /719\1/

Rule 2 is matching on any seven-digit number, keeping those matched digits, then appending “719” on to those kept digits in the replacement number. That effectively provides the seven digit dialing functionality for 719 area codes.

Now we put these rules into a translation set:

voice translation-rule 2
rule 1 /\(..........\)/ /\1/
rule 2 /\(.......\)/ /719\1/

A ten-digit number gets matched first (since that’s precedence 1) and left alone. Rule processing stops. Seven digit numbers fall to the next rule and get the area code appended.

Last steps:

- Put the rule into a translation profile

voice translation-profile addareacode
translate called 2

- Apply the profile to a dial peer in outgoing mode:

dial-peer voice 150 voip
translation-profile outgoing addareacode
destination-pattern .T

DNS-jailed Network

The goal here is to develop a network segment that’s locked down to a specific service (HTTP) and to force that segment into a specific DNS server environment for the purpose of filtering out DNS resolution of undesirable websites such as Facebook, youtube,, etc. We leverage the services from to do this. Net, we’ll be building a cheap (as in FREE) web filter for the kids. This concept can easily be extended to the Spouse, live-in Mother-in-Law, etc.

Step 1: Establish an account on (free). Here you can define the ‘Web Content Filtering’ context you prefer. At “High”, I find it filters out all the undesirable sites plus more that you may want to allow in at an “individual domain” level.

Step 2: Define a DNS view and view-list for the “kids”.

ip dns view kids
domain name-server
domain name-server
ip dns view-list kidslist
view kids 1

Here, I’m forcing DNS forwarding in this particular view to a couple of servers. Using OpenDNS's free filtering tools, you can effectively lock down browser activity.  You need to assign this DNS view to the VLAN segment where your jailbirds will reside as described here.

Step 3: If you’re going to use DHCP on this network segment, you’ll want to define a specific DHCP scope that assigns the default gateway and DNS server for the segment. Here, I’m using a 192.168.5.x VLAN for the ‘kids’. They get a router address for both the default gateway and DNS server. 

ip dhcp pool kids

Step 4: Define an ACL for this segment to lock it down to DHCP and HTTP traffic (only) and restrict DNS traffic to the router/DNS view we defined previously. Of note, even if the ‘kids’ get to a tech sophistication level where they understand how to assign a different DNS server to their interface – it won’t work. All DNS traffic is blocked other than to the DNS server we defined in Step 3.

ip access-list extended kids_inACL
permit udp any any eq bootpc
permit udp any any eq bootps
permit tcp any any eq www
permit udp any host eq domain
deny ip any any log

Cisco IOS DNS Views

DNS views are a fairly recent (12.4ish) addition to IOS to provide the capability for some advanced DNS name server functionality. They allow you to utilize the router as a DNS server and segregate DNS names + forwarding. This comes in handy when you want a split DNS environment - i.e., different name spaces and forwarding for different segments of the network. Obviously, you’re not likely to see the enterprise using the router as a DNS server – but it’s quite effective in the small network builder space (home network for instance).

The starting point in this configuration is creation of the view itself.

ip dns view internal
domain name
domain name-server
domain name-server

The command above creates the DNS view named "internal", sets the domain name to "" and sets up DNS forwarding to a pair of Google's DNS servers.

Now, I can create my own DNS namespace within that view.

ip host view internal server1
ip host view internal server2
ip host view internal server3
ip host view internal server4
ip host view internal server5

Next step is to assign the view to a ‘view list’. A view list is an ordered list of view where you can put additional restrictions. A view list is also what you assign to a network segment (interface). For this exercise, we’re just adding 1 view to a list named ‘internallist’ (note the highly creative naming conventions I’m using).

ip dns view-list internallist
view internal 1

Now, I assign the view list to a subinterface/VLAN.

interface FastEthernet0/1.1
description data vlan
encapsulation dot1Q 1 native
ip address
ip dns view-group internallist
ip nat inside

Done. Now, this VLAN has visibility to the “internal” DNS namespace above and utilizes DNS forwarding to Google’s DNS servers.