CNC Logo

Voice and Data, Part II

Peter J. Welcher and Kelly McGrew


Introduction

Three articles back, we looked at mixing voice and data, see http://www.netcraftsmen.net/welcher/papers/voice1.htm .
Since then I (Pete) have been looking into a lot of design-related issues, while coordinating a team working on an Advanced Design course. (The acronym I chose was ACID. That was an unfortunate choice, since people then shortened "Pete's working on ACID" to "Pete's doing ACID", etc., but that's another story.)

In the process of doing this, I had a chance to revisit various sources of material on Cisco voice capabilities. Also, Mentor Technologies has some instructors getting up to speed on various Cisco voice courses. One of them, Kelly McGrew, was kind enough to supply me with a choice of configurations -- so it seems like a good idea to revisit voice, this time with configurations. (I've edited and changed them, so any errors are my responsibility).

By the way, those Cisco voice / router courses -- they should start being publicly offered about when this article appears.

Voice Design

I'd like to sneak in a few changes and things I've learned since the first article.

Cisco also now has Voice over IP (VoIP) capabilities in the 2600 series (1 of the 3600 voice cards, basically), and in the 5300 (48/60 digital voice ports).

After doing some local exploration of pricing, it looks like the economics of this work in favor of combining existing voice and data lines between sites. If what you're doing now is long distance calls between those sites, then you're looking into toll bypass, and that really depends on how much you're spending on those calls.

Don't think PBX or key system replacement. They do things like "press a button, get voice mail". The routers' capability is more like connecting home phones, at least right now. You can dial, you can pass dial tones through to other devices (like a remote extension on a PBX), you can dial "9" to go off net.

Oh, but you're thinking "show me the configs...". Well, first a diagram.

A Diagram


The set of routers these configurations came from was doing Frame Relay and ATM with back-to-back connections. I've edited the configurations so they will (hopefully) look more like standard DTE router configurations.

The router r11 is a MC3810 with Digital Voice Module (DVM). The Multi-Flex Trunk (MFT) is controller T1 0, which also appears as serial 2, connected to r13 running ATM. Serial 0 connects to router r12, running Frame Relay. Serial 1 is shutdown. The DVM (controller T1 1) connects to the Channel Bank.

The routers r12 and r13 are MC3810's with Analog Voice Modules (AVM's). On r12, serial 1 connects to r11 via Frame Relay. Other serial / MFT interfaces are shutdown. Voice ports v1/1 and v1/2 are connected POTS to handsets. On r13, Serial 2 is the MFT port, using ATM encapsulation to r11, and the other interfaces are shutdown.

Router R11

no service pad
no service password-encryption
!
hostname r11
!
network-clock base-rate 64k
!
controller T1 0
 framing esf
 linecode b8zs
!
controller T1 1
 mode cas
 voice-group 1 timeslots 1-4 type e&m-immediate
clock source internal
!
interface Serial0
 no ip address
 encapsulation frame-relay
 no fair-queue
 frame-relay traffic-shaping
 hold-queue 1024 out
!
interface Serial0.1 point-to-point
 ip address 192.168.24.1 255.255.255.0
 frame-relay interface-dlci 27 voice-encap 320
 class fr1
!
interface Serial2
 no ip address
 encapsulation atm
 atm pvc 100 1 130 aal5fratm
!
interface Serial2.1 point-to-point
 ip address 192.168.20.1 255.255.255.0
 at pvc 20 5 20 aal5voice 128 64 16
!
interface FR-ATM0
 no ip address
 encapsulation frame-relay
 no ip mroute-cache
 no keepalive
  frame-relay interface-dlci 25 voice-encap 512
  fr-atm connect dlci 25 Serial2 100
!
map-class frame-relay fr1
 no frame-relay adaptive-shaping
 frame-relay cir 256000
 frame-relay bc 1000
!
voice-port 1/1
!
voice-port 1/2
!
voice-port 1/3
!
voice-port 1/4
!
dial-peer voice 1 pots
 destination-pattern 111
 port 1/1
!
dial-peer voice 2 pots
 destination-pattern 112
 port 1/2
!
dial-peer voice 4 vofr
 destination-pattern 12.
 Session-target Serial0 27
!
dial-peer voice 5 vofr
 destination-pattern 13.
 Session-target FR-ATM0 25
!
end

Router r12

no service pad
no service password-encryption
!
hostname r12
!
network-clock base-rate 64k
!
controller T1 0
 shutdown
!
interface Serial1
 no ip address
 encapsulation frame-relay
 no fair-queue
 hold-queue 1024 out
!
interface Serial1.1 point-to-point
 ip address 192.168.24.2 255.255.255.0
 frame-relay interface-dlci 27 voice-encap 320
 class fr1
!
map-class frame-relay fr1
 no frame-relay adaptive-shaping
 frame-relay cir 256000
 frame-relay bc 1000

!
voice-port 1/1
!
voice-port 1/2
!
voice-port 1/3
!
voice-port 1/4
!
dial-peer voice 1 pots
 destination-pattern 121
 port 1/1
!
dial-peer voice 2 pots
 destination-pattern 122
 port 1/2
!
dial-peer voice 3 vofr
 destination-pattern 11.
 session target Serial1 27
!
dial-peer voice 4 vofr
 destination-pattern 13.
 session target Serial1 27
!
end

Router r13

no service pad
no service password-encryption
!
hostname r13
!
network-clock base-rate 64k
!
controller T1 0
 shutdown
!
interface Serial2
 no ip address
 encapsulation atm
 atm pvc 100 1 130 aal5fratm
!
interface Serial2.1 point-to-point
 ip address 192.168.20.2 255.255.255.0
 atm pvc 20 5 20 aal5voice 128 64 16
!
interface FR-ATM0
 no ip address
 encapsulation frame-relay
 no ip mroute-cache
 no keepalive
 fr-atm connect dlci 30 Serial2 100
!
voice-port 1/1
!
voice-port 1/2
!
voice-port 1/3
!
voice-port 1/5
!
dial-peer voice 1 pots
 destination-pattern 131
 port 1/1
!
dial-peer voice 2 pots
 destination-pattern 132
 port 1/2
!
dial-peer voice 3 voatm
 destination-pattern 11.
 session target Serial2 20
!
dial-peer voice 4 vofr
 destination-pattern 12.
 session target FR-ATM0 30
!
end

So What's All That Mean?

Please note I've edited these for size. The line commands were removed. Any router and network statements (and ip classless) were removed (and not needed directly for VoFR, VoATM). ATM mapping for IP data is omitted. Etc.

Note that phone numbers 1-1-x are phones attached to router r11 port 1/x, 1-2-x is a phone on r12 port 1/x, and 1-3-x is on r13 port 1/x, just to make it easier to keep things straight.

Router r11

The network-clock command sets up the MFT clocking base (56 or 64). The controller T1 0 command then sets it up as a standard (U.S.) T1 with ESF framing and B8ZS line encoding. Controller T1 1 is setting up the DVM, and we'll leave it at that, ducking the large topic of signaling.

For sub-interface Serial 0.1, notice the new form of the interface-dlci command. The 320 is the recommended frame size for a 256 Kbps link. (See the documentation, http://www.cisco.com/univercd/cc/td/doc/product/access/multicon/3810soft/swcfg/vofrcfg.htm ).  As soon as you turn on voice encapsulation on a Frame Relay interface, data frames will be fragmented to reduce voice latency. Note that this means that an MC3810 cannot interoperate with a non-MC3810 for data over Frame Relay unless that PVC is set on the MC3810 to not fragment data. Since there's a non-MC3810 on the other end, you don't have to worry about voice or voice quality on that PVC!

On Serial 2, we set up Frame Relay tunneling over ATM (network interworking) with the aal5fratm for circuit descriptor 100 (VPI 1, VCI 130). Normally you'd only do this as part of a Frame Relay to ATM migration, where your carrier is doing the Frame Relay to ATM conversion, and at the MC3810 doing ATM you need to pull the voice back out in Frame Relay format. In this case, both MC3810's are tunneling the Frame Relay over ATM. Sub-interface serial 2.1 sets up circuit descriptor 20 (VPI 5, VCI 20) for normal VoATM.

Then interface FR-ATM0 creates a network interworking interface. Note the encapsulation frame-relay: the interface looks like a Frame Relay serial port to the MC3810. So we put a frame-relay ... interface-dlci command on the interface, just like before. The fr-atm connect maps this to the appropriate port (Serial 2) and ATM circuit-descriptor (100).

The map-class command specifies the Frame-Relay traffic shaping we want on subinterface 0.1 (note the class fr1 command there).

The voice-ports are like line commands: you put physical sorts of parameters there.

The dial-peer commands specify dial patterns, with dot (".") matching any digit. It says to the MC3810, "when you see this dial pattern, here's what to do with the call". If the dial-peer ends in "pots", it's a Plain Old Telephone Service call, and you specify the associated voice port. If you put vofr, that's VoFR, and so you specify the serial port and Frame-Relay DLCI with the Session-target line.  In this example, calls for 1-2-anything get sent out serial0 over FR DLCI 27, and 1-3-anything go to the FR-ATM0 pseudo-interface, out DLCI 25 (which maps to ATM circuit 100, or VPI/VCI 1/130).

Router r12

 This configuration is pretty much described above. Note that calls for numbers 1-1-x and 1-3-x are both sent out over Serial 1 DLCI 27. The 1-1-x calls terminate on voice ports on r11.

Due to tandem switching information in the Cisco VoFR header, the 1-3-x calls do not de-compress on r11, but get forwarded according to the specification for calls to 1-3-x. Avoiding decompression/compression cycles in situations like this preserves voice quality.

One way to think about dialed digits in the MC3810: POTS ports eat digits that match patterns, FR and ATM don't. The idea is when you dial 9 for an outside line, the PBX eats the 9 and passes any remaining digits to the outside phone switch. FR and ATM need to preserve digits to do the tandem switching behavior, when you don't have a full mesh of circuits.

Router r13

This is also as described above, changing what needs changing. Just to be a bit different, calls for 1-1-x go as VoATM out Serial2 circuit 20 (VPI/VCI 5/20), whereas calls for 1-2-x go as VoFR (network interworking) out FR-ATM0 DLCI 30, which is ATM circuit 100 on Serial 2 (VPI/VCI 1/130).

When troubleshooting, you have to play "follow the call". Good luck, and don't lose your voice!


Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net . 



Copyright 1998, Peter J. Welcher