With most business that integrate VoIP into their network, they not use VoIP technology within their own LAN but also across WAN's to remote sites, other businesses, ISP's, etc. There are a few popular voice trunking protocols to pick from and I'm starting to learn the history and details behind each. There are four voice gateway protocols that I hear and see configured quite a bit in the voice networks I've seen so far.
1. H.323: This is a pretty mature and older voice protocol that was created primarily for connecting to other networks using the ISDN connection. This doesn't surprise me as I see this used mainly on PSTN connections to ISP's. While the protocol is pretty stable, there are a lot of features newer protocols handle better along with being easier to manage. When I run the debug command debug isdn q931 on a gateway, the information is usually pretty cryptic and hard to undertstand.
2. MGCP: I see this protocol used all the time in the Cisco VoIP networks, apparently Cisco is really the only vendor that uses this protocol even though it's an open standard. MGCP is a centralized based configuration.
3. SCCP: Again this is only on Cisco VoIP networks because this is Cisco's proprietary protocol. This protocol is used specifically for communication with Cisco IP Phones and other Cisco endpoints such as ATA's.
4. SIP: This is the new kid on the block and it's still being developed constantly. SIP is basically a lighter and more feature rich version of H.323. Except that it is based on VoIP instead of ISDN, it uses a lot of the same standards that HTTP uses which makes it a lot simpler to develop. I haven't touched SIP yet but I've heard a LOT about it. There's actually a forum that is very involved with this new protocol, check it out at www.sipforum.org
A personal detailed view of a journey of acquiring IT certifications and career progression.
Saturday, October 16, 2010
Sunday, October 3, 2010
First Hands on With QoS
As I dive deeper into the VoIP world, I'm starting to learn just how important QoS (Quality of Service) is in a network. QoS is a complicated topic and for good reason, not only because the configuration can be quite involved, but also their can be a lot of corporate politics involved. QoS comes into play when a network is congested, instead of having a router just drop random packets that it can't route you can prioritize which specific packets should be sent from most important to least important. With the least important being sent to the "bit bucket (gone forever)" most likely. With this said RTP voice traffic is very time sensitive, when there is latency it upsets the way it is sent to the receiving end and in turn usually upsets the end user as it can cause echoing, dropped calls, and a plethora of other issues.
You should prioritize voice and video traffic before other traffic in most environments...well unless the CEO steps in and demands that his e-mail and internet traffic is more important than any other traffic! There are essentially 3 steps to configuring QoS:
1. Identify and match packets with the class-map command
2. Prioritize traffic with the policy-map command
3. Assign the QoS policy to the impacted interface with the service-policy command
You can see a sample configuration in the picture above that I was messing around with in GNS3.
The Many CME Phone Features
Over the last few weeks I've been reading and toying with the many different phone feature settings that you can configure through CME. While there are still many options I haven't covered quite yet such as Intercom, Music On Hold, and Paging, I've learned a lot about what you can do using the ephone commands on the CME gateway. By far the most confusing part for me has been the configuration of hunt groups and how to route and stop the calls within hunt groups and to other hunt groups. It's a lot easier to understand when you're looking at a full Call Manager GUI rather than from ephone-dn commands!
Sunday, September 19, 2010
DHCP IP Exclusion Command
As I was reading one of the CCNA:Voice chapters I noticed that my phones were picking up the wrong VLAN IP addresses. I spent hours and hours today working the issue until I realized what it was. My DHCP router has two dhcp pools to pick from when handing out IP address, one named VOICE for my IP phones (172.16.1.0 /24) and one named DATA (172.16.2.0 /24) for PC's and everything else simply enough. I like to exclude a small range of IP's from being handing out becuase you'll see this in most real world environments. So I excluded 10 IP's on both dhcp pools, 172.16.x.1 - 10 which allows me 20 IP addresses for servers, future routers, etc. Well what I didn't pay attention too was that I accidentally excluded the range 172.16.1.1 to 172.16.2.10 instead of this:
172.16.1.1 to 172.16.1.10 (10 spare IP's on the VOICE VLAN)
172.16.2.1 to 172.16.2.10 (10 spare IP's on the DATA VLAN)
I didn't notice that this was causing the issues because it was still handing out IP's but only from 172.16.2.11 on up obviously. Once I caught the error and typed this command:
ip dhcp excluded-address 172.16.2.1 172.16.2.10
ip dhcp excluded-address 172.16.1.1 172.16.1.10
Sure enough both phones picked up the right IP addresses, well after I restarted the phones from the voice router that is.
Sunday, September 12, 2010
Internal VoIP Network
I'm finally back from traveling and had some downtime to begin studying once again. I was able to finish setting up my internal VoIP network and I can place calls between both phones now. The configurations for the phone settings is done through the router CME using ephone commands. I assigned one phone extension 1001 and the other 2002. Once I get a little further in my studying I'm going to configure the T1 connections between my two 1760's to simulate placing calls to a remote site over a WAN link. I'm planning on taking the CCNA:Voice test before the end of the year so I can begin ramping up for the CCVP a little after April once I'm in my new place.
Monday, August 30, 2010
Uploading CME Files
I spent most of this evening trying to upload the full featured Call Manager Express (CME) tar files to my Voice router. I was doing very well until I realized that I didn't have enough Flash memory to support the full version! Thankfully I was able to find the basic version which should be enough to get me through the studying and the test.
It was very time consuming deleting all the old files but I did learn a new command which I've never heard of, it's called the squeeze command. It's for sure one the weirdest command names in the Cisco IOS. Here's how it works, by default when you delete a file from flash, it really doesn't delete it rather it marks it as deleted so you're not gaining your flash memory space back by just typing the delete flash: command. The squeeze command however goes through the entire flash directory and removes any files marked as deleted, it works fairly well but is time consuming also.
Sunday, August 29, 2010
Beginning The Setup of My Voice Network
I've been really busy over the last few months with this one being the busiest with me working 16-22 hour days. This is due in part of me installing and bringing up new networks for a few of our remote sites that's growing in size. I'll be in St. Paul MN this Wednesday and won't be back until Tuesday of next week if all goes well. I finally had a little downtime to get some studying in. After about 1 month of researching and about $700 later I had purchased everything I needed for my CCNA: Voice lab.
After I plugged everything in I did some of the initial configuration based on the CBTNuggets CCNA: Voice videos. I ran into an issue that stumped me for a long time however which was due to none of my phones or PC was receiving an IP address from the DHCP server I configured on my 2620 router. It turns out that my 7960 and 7940 didn't like the simplified vlan configurations much on my switch.
I had the following configured at first:
switchport mode access
switchport access vlan 50
switchport access voice vlan 10
I had to change the configuration to the old way:
switchport trunk encap dot1q
switchport mode trunk
switchport trunk allowed vlan 10,50
switchport access vlan 50
Once I added this all my devices starting picking up IP addresses. The only thing I can think of at this point is that maybe the older IP Phones don't accept the new way of switch vlan configuration but I'm sure I'm wrong and may be missing something.
Subscribe to:
Posts (Atom)