My current employer is a medium sized call center with IPCC Express used for their contact center solution currently. I'm still learning my way around UCCX but I'm getting there, I can program basic scripts and troubleshoot basic issues. We use over 40 different queue scripts that all calls out to the same default holiday script. This script then points to a very simple XML file that lists calender dates that is edited with notepad. If the holiday condition is met, the original script then inputs the variable set (usually set to change to the "closed" setting).
There was one queue that was supposed to be open today (oops) so I had to create a duplicate script called "holiday_Alternate" that called out to a similar XML file except it didn't have today's date (11/26/2010) listed therefore the original queue script was set to open instead of closed.
Friday, November 26, 2010
Thursday, November 25, 2010
Configured My First ASA this Week
I configured my first ASA this week and what a mess it was! Oh well it was a good intro to getting hands on with some of the security side of things. When one of our remote sites was initially built, there wasn't any internet availability in the area due to it being in a more rural location. To remedy this, all internet traffic was delivered over our MPLS and then out of our corporate site to access any external website. Recently the area finally offered simple business DSL connectivity (that was more than enough for this location) and we asked for this service pretty quickly.
Well of course we didn't want to just connect a non-secure DSL connection to our network so we needed a simple firewall aka ASA 5505 to provide a buffer between our remote sites network and the outside world. Once all was said and done/configured it was actually pretty simple but I ran into many bumps along the way. The first thing was that the new ASA had NO configuration whatsoever on the device, not even the factory-default settings. The device was asking for a username and password which wasn't configured so after about 3 hours of mucking around I ended up finally getting in by using the ROMMON mode and changing the configuration register to 0x41. This tells the ASA to ignore the saved start-up configuration, from there I entered the command configure factory-default which put the right factory default settings on the device it should of had to begin with.
The only thing I could think of is that maybe they forgot to throw this command on the device before shipping it out lol. After that fiasco now I had to figure out to configure it finally! It wasn't to bad but I ran into some weird things mainly due to the silly DSL modem itself. The DSL provider configured the modem to work in "pass through" mode so it didn't do anything besides provide a bridge between the ISP and the ASA, it took me a while to realize that. So I had to battle NAT configuration, IP Addresses, and ASA port configuration.
What confused me the most was how I had to tell the ASA what it should and shouldn't know. The ASA had no problems reaching the internet or the internal network. However internal devices could only reach the ASA and not the external world, not even the ASA's outside interface. At first I thought this was due to access-lists I had configured. Turns out it was because NATing wasn't configured all the way and I hadn't specified the internal network IP range the ASA should know about.
I used ASDM and even a little CLI to finally get the thing working. Commands I'll never forget is the route inside and route outside which is similar to the ip route command used on routers and L3 switches.
Well of course we didn't want to just connect a non-secure DSL connection to our network so we needed a simple firewall aka ASA 5505 to provide a buffer between our remote sites network and the outside world. Once all was said and done/configured it was actually pretty simple but I ran into many bumps along the way. The first thing was that the new ASA had NO configuration whatsoever on the device, not even the factory-default settings. The device was asking for a username and password which wasn't configured so after about 3 hours of mucking around I ended up finally getting in by using the ROMMON mode and changing the configuration register to 0x41. This tells the ASA to ignore the saved start-up configuration, from there I entered the command configure factory-default which put the right factory default settings on the device it should of had to begin with.
The only thing I could think of is that maybe they forgot to throw this command on the device before shipping it out lol. After that fiasco now I had to figure out to configure it finally! It wasn't to bad but I ran into some weird things mainly due to the silly DSL modem itself. The DSL provider configured the modem to work in "pass through" mode so it didn't do anything besides provide a bridge between the ISP and the ASA, it took me a while to realize that. So I had to battle NAT configuration, IP Addresses, and ASA port configuration.
What confused me the most was how I had to tell the ASA what it should and shouldn't know. The ASA had no problems reaching the internet or the internal network. However internal devices could only reach the ASA and not the external world, not even the ASA's outside interface. At first I thought this was due to access-lists I had configured. Turns out it was because NATing wasn't configured all the way and I hadn't specified the internal network IP range the ASA should know about.
I used ASDM and even a little CLI to finally get the thing working. Commands I'll never forget is the route inside and route outside which is similar to the ip route command used on routers and L3 switches.
Sunday, November 21, 2010
CME Music On Hold
Ever since I've read past the CCNA:Voice section regarding Music on Hold (MOH) I've been trying to get it working ever since. The problem I ran into is that I couldn't get MOH to work when I placed a call from one IP Phone to another in my internal network, just dead silence. After some research, apparently this a known issue depending on how you configure MOH. In order for this to work between IP Phones in your internal network, you're supposed to use multicast rather than the default method. Even with multicast configured and every option I could think of, I still couldn't get this working.
Well after completely forgetting about MOH and eventually setting up my remote network weeks later, I was reviewing a few CBT's when it hit me that MOH should work when putting external callers on hold. I placed a call to the analog phone on the remote network and then put them on hold, sure enough it worked! I will admit though that the quality wasn't great because I was using the G.729 codec across my WAN and I'm betting that this analog phone is at least 15 years old!
Well after completely forgetting about MOH and eventually setting up my remote network weeks later, I was reviewing a few CBT's when it hit me that MOH should work when putting external callers on hold. I placed a call to the analog phone on the remote network and then put them on hold, sure enough it worked! I will admit though that the quality wasn't great because I was using the G.729 codec across my WAN and I'm betting that this analog phone is at least 15 years old!
Thursday, November 11, 2010
The Smart Business Communications System
I finally knocked out the book for the CCNA:Voice this evening, the last two chapters were based on the Smart Business Communications System (SBCS). To be honest both chapters felt like one huge sales pitch but there was some useful information that I'm sure will be on the exam. As far as I understand, the SBCS suite is based around the Cisco UC500 product family and how they interconnect between each other.
The main player within the SBCS is the UC520 ISR which is pretty slick within itself, especially if you're a non-Cisco person. It enables you to have a router, firewall, POE switch, PBX, Wireless, and many other features within one small device. The UC520 itself seems fairly straightforward, especially with the web based GUI tool called Cisco Configuration Assistant (CCA). Now that I finish these last few chapters it's time to review over the next few weeks and then exam time!
The main player within the SBCS is the UC520 ISR which is pretty slick within itself, especially if you're a non-Cisco person. It enables you to have a router, firewall, POE switch, PBX, Wireless, and many other features within one small device. The UC520 itself seems fairly straightforward, especially with the web based GUI tool called Cisco Configuration Assistant (CCA). Now that I finish these last few chapters it's time to review over the next few weeks and then exam time!
Monday, November 1, 2010
Cisco Unity Express Hardware Limits
It's important to know that you're limited with voice mail size limits based on the Cisco Unity Express hardware itself. Below I have listed the four different hardware size's and their limitations that I'm assuming will be on the exam:
- Cisco Unity Express Advanced Integration Module (AIM-CUE)
14 hours of storage
4-6 ports for voice sessions depending on the router model
- Cisco Unity Express Network Module (NM-CUE)
100 hours of storage
8 ports for voice sessions
- Cisco Unity Express Network Module with Enhanced Capability (NM-CUE-EC)
300 hours of storage
16 ports for voice sessions
- Cisco Unity Express Enhanced Network Module (NME-CUE)
300 hours of storage
24 ports for voice sessions
Sunday, October 24, 2010
Complete Voice Network
Today I wrapped up the last bit of configuration I needed to do to complete my CCNA:Voice lab setup (besides Unity Express). I am now able to place calls not only internally but also to my remote site via a PSTN connection. I have four more chapters to go and then it's time to review and prepare for the test. I want to take and pass the exam sooner than later because the certification is being completely revamped and I only have until February 28th to take to current version. I already feel pretty confident, especially after I was able to finally dig into dial-peers and the many ways you can manipulate them.
Saturday, October 16, 2010
VoIP Trunking Protocols
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
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
Subscribe to:
Posts (Atom)