Monday, January 9, 2012

CME - VG224 Interoperability

        There are a few ways to configure a VG224 to work with Cisco CallManager Express. 

Skinny (SCCP)
        This Layer 2 option treats the VG224 as a SCCP device or phone. There is very little configuration on the VG224 router other than the SCCP integration with CME. Think of the VG224 as a device containing 24 ephones. Configuring each voice port with "service stcapp" converts an FXS port to a SCCP phone, so this must be done to all VG224 voice ports.

Example:
(VG224)
sccp local FastEthernet0/0
sccp ccm 192.168.25.2 identifier 10
sccp
!
sccp ccm group 1
associate ccm 10 priority 1

dial-peer voice 200 pots
 service stcapp
 port 2/0
 .


H.323
        The Layer 3 option treats the VG224 as a separate voice gateway. There is much more configuration on the VG224 router, but less configuration on CME. When CME receives a call, it uses its outbound dial-peers to send the call and one or more of those outbound dial-peers points to the IP Address of the VG224.

Example:
(CME)
voice service voip
allow-connections h323 to h323
 !

interface GigabitEthernet0/1
ip address 192.168.25.1 255.255.255.0
no ip mroute-cache
duplex auto
speed auto
h323-gateway voip interface
h323-gateway voip bind srcaddr 192.168.25.1
!
dial-peer voice 100 voip
incoming called-number .
dtmf-relay h245-alphanumeric
codec g711alaw
no vad
!
dial-peer voice 200 voip
destination-pattern 200
modem passthrough nse codec g711alaw
voice-class h323 1
session target ipv4:192.168.25.2 
codec g711alaw
fax rate disable
fax protocol none
no vad



(VG224)

h323
!
voice class h323 1
h225 timeout tcp establish 3
!
interface FastEthernet0/0
ip address 192.168.25.2 255.255.255.0
duplex auto
speed auto
h323-gateway voip interface
h323-gateway voip bind srcaddr 192.168.25.2
!
dial-peer voice 100 voip
description OUTGOING TO CME
destination-pattern OT
modem passthrough nse codec g711alaw
session target ipv4:192.168.25.1
voice-class h323 1
codec g711alaw
no vad
fax protocol none
!

dial-peer voice 101 voip
description INCOMING FROM CME
incoming called-number .
modem passthrough nse codec g711alaw
voice-class h323 1
codec g711alaw
no vad
fax protocol none
 

dial-peer voice 200 pots
description INCOMING TO VG PORT
destination-pattern 200
port 0/0
forward-digits all





.
Posted by at No comments:
Labels:

Thursday, January 5, 2012

UCCX - Agents Stuck In Certain State

        In all version of UCCX, I've noticed that Agents can get stuck in a certain state (Reserved, Talking, Not Ready, Ready). Here are some reasons best practices to follow to hopefully avoid or resolve this issue.
  • The biggest violator is misconfiguration. This is what you shouldn't do:
    • Do NOT configure two lines on an agent's phone that have the same extension, but exist in different partitions (eg. Internal_PT, and UCCX_PT)
    • Do NOT configure the same ICD extension on multiple phones
    • Do NOT configure Call Forwarding on an ICD line prior to CRS 3.1
    • Do NOT configure a Max Busy Trigger of anything other than 1 on an ICD extension (Agents can only receive one call at a time)
    • Do NOT set the CUCM ICD extension's No Answer Ring Duration (Default or Static) to be less than the UCCX Select Resource Timeout value. 
      • On the Extension the setting is under "No Answer Ring Duration"
      • In Service Parameters > Cisco CallManager it is under Clusterwide Parameters (Forward) > Forward No Answer Timer and defaults at 12 seconds.
  • CSCeb36950 - Do NOT configure any GOTO steps that point to a label within the Select Resource step. Always point to a label before the Select Resource Step.
  • CSCdx46617 & CSCeb49310 - Set a 1 second delay step at the beginning (before the Accept Step) of all of your scripts. This is to prevent callers getting stuck in queue and not being able to be reached as well as agents getting stuck in a certain state. 
    • Typically a transfer redirect step from one script or queue into another script causes issues if there is no delay set. The redirect is too fast for the call to be marked as handled and then accepted and handled within another script.
    • Agents are typically left in the RESERVED state and the caller is typically left in a routing loop and cannot be answered. The caller must drop off and call back in.

Resolutions and Rules:
  1. Configure only one unique ICD line per phone
  2. Do not configure an ICD extension that is used by any other extension in any other partition
  3. Add a 1 to 2 second delay step to all of your scripts before the Accept Step
  4. Statically set the Forward No Answer or No Answer Ring Duration to a value higher than the UCCX Select Resource Timeout value
  5. Always add a SetContactInfo step to the Successful branch of a Redirect Step
  6. Do NOT configure Labels within the Select Resource step and have a GoTo pointing to it from the outside of the Select Resource step





.
Posted by at No comments:
Labels:

Tuesday, January 3, 2012

UC on UCS - Where to Start

        There is a big push for all UC Appliances to go virtual. This push comes from all the awesome benefits/features of virtualization, Cisco emerging and exploding in the server hardware arena, and from the IT architects and directors who want to stay current or  push the envelope.

        So you want Cisco UC to be virtual, but where do you start and where are the instructions?  From an information/instruction perspective, Cisco is moving towards Online Wiki's because of the speed in which they may publish information. The old days of 4-month literary approvals and information releases are gone. The snail's pace of releasing documentation doesn't make sense in a rapidly advancing and evolving arena such as virtualized Unified Communications.

Start here:


1) Considerations
        You want to make sure that what you're about to buy is compatible. The question is how compatible do you want it to be? There is Super Compatible (down to a gnat's ass), then there's Compatible (okay it works *fingers crossed*), and then there's Incompatible (this thing just doesn't work).

Tested Reference Configurations (TRC) - Super Compatible!
  • http://docwiki.cisco.com/wiki/Tested_Reference_Configurations_%28TRC%29
  • TRC's are for these type of customers
    • lower levels of virtualization proficiency
    • require guaranteed UC app virtual machine performance when the solution elements under Cisco UC's control are configured correctly per UC support policy
    • desire Cisco to handle hardware sizing, determining hardware specs and translating those specs into a hardware parts list to ensure the above guarantee
    • are willing to accept as tradeoffs for the guarantee less choices for hardware and less choices for virtual machine deployment options.
    • TRC's typically come packaged in a single part number - yay!!
 Specs-Based VMware Hardware Support - Compatible
  • http://docwiki.cisco.com/wiki/Specification-Based_Hardware_Support
  • Specs-Based is intended for customers with extensive expertise in virtualization and server/storage who wish to use their own hardware standards.
    • The hardware choices have not be directly tested/documented by Cisco (since they didn't choose the configurations... you did!!)
    • Cisco is not responsible for the screw-ups you caused. That being said, I think it would be difficult to pin-point many issues back to the hardware configuration unless you did a pretty shoddy job of choosing and sizing.
    • A good rule of thumb is to follow the TRC specs or choose hardware better than what the TRC has tested.
Sizing Network Hardware and QoS Considerations

2) Implementing
        So your hardware has arrived, but now what?

Configuring Hardware Platforms
  • Raid configuration, BIOS settings, firmware upgrades/configuration and monitoring of hardware health
Installation

3) Building UC Appliances
        You've installed ESXi 4.1 and vSphere. Now after all of that, you still need to build out your UC applications!

Building the VMs
  • OVA/OVF (Open Virtualization Appliance/Format) is a game changer.
    • These small files can be downloaded on Cisco.com under the appliance you're looking to install. The OVA templates build out the required virtual hardware specs that are supported by Cisco.
    • You don't have to build or spec out the hardware. Just deploy the OVA!!
  • Once your machines are built you can proceed with the standard install procedures.
  • Do not use Snapshots (especially Snapshots with memory) as they are not supported for Cisco UC applications and they can take your system down and take up hard drive space.
    • Use cloning or templates!

4) Some Key Reminders
  • Make sure you are fully licensed
    • The trial runs out in 60 days and then your VMs won't turn on!
  • Configure the auto power-on sequence upon host start-up
  • Again, no Snapshots!
  • Set alarms/alerts so that you're kept in the loop on the health of your host(s)
  • Setup vCenter if you have more than one host
  • Upgrade VMware tools!!
  • Configure backups for your UC appliances
  • Make sure to review the system utilization (hard drive, memory, CPU, etc.)



.
Posted by at No comments:
Labels:
Subscribe to: Posts (Atom)