Archive
All about UC 500
Technical Enablement Collateral Helps Partners
This document includes:
- Links to documents and Materials you need to be famaliar with
- Technical Enablement Labs that show you how to configure basic functions
- TEL Template
This is a community document open for editing as you see fit.
Links to Documents
For any Partner who wants to build a successful practice deploying UC 500 (the new UC 540/UC 560 or the legacy UC 520), there are certain materials you need to become famaliar with and as well some actions you need to take to have your Technicians and Engineers feel comfortable building and deploying UC 500.
Small Business University
Select Certification <– for both AM and SE
First Look SBCS UC540 2.0 Lab
Distance Learning Opportunity for Channel Partners <– for both AM and SE
Smart Designs
Design and implementation notes to show typical deployments <— for the SE
Integrating the UC 500 System with an Existing Customer’s Firewall
SBCS Feature Reference Guide (CCA configurable)
No longer requires login; accessible to partners and customers. <– for both AM and SE
The CCA Release Notes http://www.cisco.com/en/US/products/ps7287/prod_release_notes_list.htmlwill give you additional information about whats new as well as any known issues with each release
The CCA Prerequisite Checks must be performed on the PC you plan to run CCA on and will save you days of wasted time
Platform Reference Guides <– for the SE
make sure you understand the SKUs supported and the capacity of the system as defined in these great guides
Quick Pricing Tool (QPT) <— for the AM and SE (reduce Quoting time from Days to Minutes)
http://www.cisco.com/web/partners/sell/enablement/quickpricingtool.html
Collect what you need to build the system (much of it in a staging environment) before you deploy on site.
SBSC System Test information (how it was tested, which code was used, what the results were)
https://supportforums.cisco.com/docs/DOC-13362
Third Party Applications to be understood:
https://supportforums.cisco.com/docs/DOC-9780
In addition to emmedded applications like SNR, WEBEX, TCV, IMAP Mail Integration, Video telephone, learn about third party integrations
Possible Milestones you can achieve as a measure of your ability to deploy.
- Select Certification and identification of key individuals in for roles and responsibilities
- get NFR Gear (UC500, ESW switches, Phones, AP541s, which you can demo to your customers)
- Training touches – attend the virtual trainings and perform the TELs below in this document
- Build your lab
- Perform Demos
SBCS User Guides (including phones):http://www.cisco.com/en/US/docs/voice_ip_comm/sbcs/roadmap/sbcs_uc500_roadmap.html
Get the Latest CCA Code: www.cisco.com/go/configassist
Let the Latest UC500 Bundle: https://supportforums.cisco.com/docs/DOC-9829/
Please take a look at the UC 500 Software Pack Roadmap posted at https://supportforums.cisco.com/docs/DOC-9827
Office Manager (OM) Information and SW
Office manager Installation Guide
Technical Enablement Labs (TEL) and Videos (VOD)
As SBCS moves forward, it does so with the UC 500 SWP, a given CCA version and the Office Manager (OM) version that work together to deliver new features and functions. This TEL lab area is updated by partner demand on the support community, many times to answer discussion threads that we feel should be answered more completely with lab demonstration. While we try to obsolete older labs to the bottom, there are still some older labs not yet replaced and so you should always consult the CCA OLH and Admin Guide as well as latest Smart Designs (which normally lag behind TELs but become more officially supported docs).
When we Announced CCA 3.0 and Office Manager 1.2, we delivered two Partner Webcasts and the .ppt used are here:
CCA 3.0 (new capabilities) Demonstrated (Webcast ppt from 1/13/2011)
Office Manager 1.2 technical Webcast/demo for partners 1/20/2011
Initial Maintenance and Configuration with CCA
Creating and Managing Customer Sites with CCA TEL
SW Upgrade: SWP 8.1.0 with CCA 3.0 TEL
Configuring a UC500 Demo System with CCA 3.0 TSW and Bulk User and Phone Import
UC 500 Localization using CCA 3.0 SW Upgrade Utility VOD
TSW for Bulk User and Phone Data Import using BulkDataImport.xls in CCA 3.0 VOD
Upload and Download files to UC 500 Flash using CCA 3.0 VOD
Upgrading or Installing a New License on a UC540/560 using CCA 3.0 TEL
Features and Functions Labs and VODs
The Remote Teleworker Router Configuration with CCASPA525G_SSL_Remote_TEL_19.pdf
SPA525G Remote SSL VPN Teleworker to UC 500
Users And Extensions Assignment in CCA 3.0 with Hold Alert and Speed Dial TEL
http://www.youtube.com/watch?v=WzQ72IIZhysCUE Connectivity Status Diagnostics and Recovery with CCA VOD
Multiple WAN IP to LAN Static NAT Mappings with CCA 3.0 VOD
CCA Tele-worker Phone Support MTP Configuration VOD
Live Record Configuration and Beep Adjustments with CCA 3.0 TEL
Removing Live Record Beep Tones with CCA 3.0 VOD
Configuring Combined Paging Groups with CCA TEL
Paging Group Configuration with CCA VOD
SKYPE for SIP Configuration with CCA TEL
Configuring Remote Access to Administraton via Telephoine (AvT) for your AA with CCA TEL
Auto Attendant Script Customization (Alternate Greeting and Dial by First Name) with CCA TEL
Assigning FXO ports as “CO Lines” and assigning them to phones
Manual Override to AA TOD Schedule using Night Service
Configuring the UC500 to work with Call Accounting and Call Recording from ISI
SA500 Configuration with CCA TEL
Configuring and Operating FXO Trunk Groups with CCA TEL
Hybrid Key System Configuration with CCA
Webex Phone Connect configuration with CCA 3.0
Lab 3: UC540 EZVPN Configuration
Lab 4: SIP Trunk Configuration
Lab 6: SA500 Security Applicance in front of a UC500 with SIP trunking
Lab 7: B-ACD (Basic ACD) Configuration
Lab 8: Auto Attendant and Night Service
Lab 9: Multisite using CCA 2.1 Multisite Manager
Lab 10: Protect Link Gateway Service on SA 500 in front of UC540
Lab 11: Smart Application: TimeCardView
Lab 12: Smart Application – IMAP Unified Messaging
Lab 14: Unified CallConnector (UCC)
Lab K: Traffic Shaping and Max Connections (CAC),
Lab 15: SR520-T1 Configuration with CCA
Lab 16: Video Monitoring xVC2300 IP Cameras from SPA525G Phone
Lab 17: Smart Call Connector Attendant Console Operator
Lab 22: Disable Cisco IP Phone WEB Server access on UC500
LAB 24: NTP on SBCS (UC500 & SBCS)
Lab 25: TheOffice Demo configured using CCA 3.0 (Updated)
How to DEMO the OFFICE SBCS - Demo Guide
The actual DEMO Performed (54 minutes run time)
Lab 26: SNR Smart Application Configuration and Operation on UC500 with CCA
Lab 28: UC560 Voice Mail Expansion using upgrade of external CUE Flash to 8G
Lab 30 UC500 Access List Manager – An example on how to restrict Guest Network access
NOW OBSOLETE Labs Archive (based on older SWP and CCA version)
LAB 1: UC540 Initial Connection, Discovery, SW Upgrade, Phone Load Management, and Licensing
Lab 13: Smart Application – Live Record
Lab 20: Cisco Phone Firmware Upgrade (79xx models – manual)
Lab 23: Paging Groups on UC500
Lab 18: Auto Attendant custom script configuration for ‘no action transfer
Lab 21: SMTP Notification of UC500 Voice Mail to EMAIL
Lab 27: Configuring Alternate Greeting on UC500 Auto Attendant
Lab 2: UC540 Telephony Setup Wizard in Staging (staging without phones)
CCM 9.X New Features
Pause in Speed Dial
Users can configure speed dials with FAC, CMC and post connect DTMF
Comma accepted in speed dial as delimiter and pause
Feature allows two methods of configuration:
-Method 1: Using comma as a pause and also as a delimiter
-Method 2: Dialstring/FAC/CMC/Post connect digits with no commas
Method 1: Command Delimiter for Pause
-Comma used to delineate dial string, FAC, CMC, and post connect digits
-For post connect digits, commas insert a 2 second delay
-Commas may be duplicated to create longer delays
-Preferred method for non-CUPC devices
Method 2: No Comma
-All digits to be used for dial string, FAC, CMC and post call digits entered as one string
-Once a digit string has been matched, CUCM moves on to next digit string
-Can be used on SCCP and SIP phones, but required for CUPC
Pause in Speed Dial Examples
-914085551212,,,,123456
-Will dial 914085551212, after connect, wait 8 seconds to dial 123456
-90114455612323#,2244
-FAC for International Calls. Will dial 90114455612323# with FAC of 2244
-914085551212,6534,5656,,,9933
-Will dial 91408551212, with a FAC of 6534 and CMC of 5656, wait 6 seconds, the dial the DTMF digits 9933
-914085551212653456569933
-Will dial 914085551212 with a FAC of 6534 and CMC of 5656, then immediately after connect, dial 9933
New Service Parameter allows configuration of interdigit delay
If the speed dial FAC or CMC is wrong
-Method 1: Call disconnects and an error is displayed
-Method 2: phone displays an error and allows user to manually enter information
Pause in Speed Dial Caveats
-Dial string is truncated in the calls history list (only dialed number)
-Feature may not work with CUPC client and variable length/overlapping dialplans (no comma delineation)
-This feature is not supported SRST
Codec Preference
Pre CUCM 9.0
-Administrator could only eliminate codecs (based on Maximum Audio Bit Rate)
-Could not prioritize G.711alaw over G.711ulaw, or G.729 codecs
With CUCM 9.0
-System default codec preference same as earlier versions
-Allow administrator to deterministically specify codec order
-Allow codec selection based on received offer
-Custom Codec list applied globally or on a GW/Trunk Level
-Can be applied to: SIP, MGCP, SCCP, H323 and EMCC
Codecs preference still choose by Regions
For SIP Devices/Trunk, can specify “Accept Codec Preference in received Offer”
Can change codec selection for EMCC logged in devices
Codec Preference Caveats
A common Codec Preference List must be the same on all clusters when using the following features:
-Extension Mobility Cross Cluster
-H323 Inter Cluster Trunks
Biggest challenge will be unexpected codec
-Check “Accept Audio Codec Preferences in Received Offer” settings
-Check at Device level and system level
When using non-pass through MTP, codec negotiated hop-by-hop
Native Call Queuing
Enables Hunt Pilot to queue callers
-Allow for redirection of calls based on different queue criteria
-Allow agents to participate in multiple queues
- Auto logout and call re-queue if agent does not answer
- Longest waiting call in all queues will be delivered first
- No ‘post call’ time or agent greeting options
- On phone ‘Queue Status’ display
Cisco Extend and Connect
What is the existing limitation?
- Using CTI (webex connect or CUCILync), user can monitor a calls, but not control the call
- No enterprise features for non-CUCM registered devices
- Cannot hold/resume, transfer, conference or park
- Remote devices ring and can be answered, but not mid-call features
What is Cisco Extend and Connect?
- A new device type, CTI Remote Device that represents all remote destinations for a user
- Anchors enterprise calls on the CTI Remote Device
- Allows a CTI application (like Jabber) 3rd party control of the remote connection to enable enterprise call features
Examples of a deployment scenario
Contact Center agent working from home
- Low bandwidth at house, VOIP not an option (hard phone or soft client) and cell phone is not an option
- Extend connect sends call to home phone and CAD agent allows enterprise features needed for contact center agents
Use Cisco Unified Communications with legacy PBX
- Customer has PBX under contract and not ready to move phones
- Customer wants UC for IM, Chat and messaging, but phones on PBX
- Extend Connect enables Jabber deployment for UC, but enterprise control of PBX phone (as remote device for Jabber)
New End User Webpages
CUCM 9.0 now has two types of end-user’s webpages
- One type of page is for core Users with one phone and one line
- The other page will be for users with multiple phones with one or more lines on each device
New User Page UI targeted towards core users
Cisco Mobility Updates
Simultaneous Ring in previous versions of CUCM
- CUCM 7.0 introduced the parameter “Reroute Remote Destination Calls to Enterprise Number”
- Calls direct to cell would ignore time of day settings and call the cell
- Calls would be anchor on the enterprise phone….but the line would not ring
New features in CUCM 9.0:
- Added “Ring All Shared Lines” service parameter
- Uses Boolean Setting
- True – all lines (including other remote destinations) ring
- False – only the dialed number (remote destination) rings
- Default and existing behavior is False
Single Number Reach Voicemail
The Problem:
- When a call is extended to a SNR destination, CUCM cannot determine if the call was answered by the user or VM
- Based on “Answer Too Soon”
- Time based mechanism is unreliable and requires tweaking for each service provider
New Solution
- CUCM 9.0 introduces a new parameter called “Single Number Reach Voicemail Policy”
- Can be either Timer Controlled or User Controlled
- Timer Controlled uses existing “Answer Too Soon” timer
- User Controlled requires the user to send a signal (DTMF) to accept the call
Hunt Pilot Connected Number Display
Hunt pilot DN display in previous versions
-Calls to a hunt pilot display the DN of the hunt pilot as the connected party ID
- Applies to both MGCP and SIP trunks
Hunt pilot DN display in CUCM 9.0
- This feature allows the connection to be updated with the answering party’s DN as the Called Party ID
- Applied on the Hunt Pilot Configuration page
- SIP: PAI and Remote PartyID are updated
- MGCP/H323: Connected Number sent to update the Called Party ID
RTCP Support
RTCP
- RTCP provides out-of-band statistics and control info for RTP
- RTP sent on even port and RTCP is send over next higher odd port
- RTCP is supported between phones directly
RTCP not supported by:
- Trusted Relay Point (TRP)
- RSVP Agent
- DTMF Translator
- Passthru MTP
CUCM 9.0 RTCP New features:
- CUCM 9.0 supports RTCP through MTP in pass thru mode
- In non-pass thru mode, RTCP will still be blocked
- Only valid for SIP to SIP calls
BRI G.Clear
- CUCM v7.0 (1) first introduced G.Clear support for MGCP PRI
- G.Clear required for tandem ISDN bearer circuits in VOIP network
New features:
- CUCM 9.0 expands support for G.Clear to BRI interfaces
- Supported on MGCP BRI interface
- Supports G.Clear over SIP trunk with Early Offer and G.Clear
Security and OS Updates
- Red Hat Enterprise Linux 5.0 v7.0.2
- Host rename/reIP simplified (3 less steps to complete)
Optimized CLI commands:
- Utils dbreplication stop/dropadmindb/reset
- Utils dbreplication forcedatasyncsub
- Utils dbreplication status replicate
- Utils dbreplication runtimestate
Upgrade paths
- L2 upgrade from 8.6(1) and later to 9.0(1)
- Refresh Upgrade for 8.x (prior to 8.5), 7.1(5) and 6.1(5)
Security Feature Update
CTL Client Update
- Single installer for all Windows versions
- Supports Windows 7 (32 and 64 bit), Windows XP and Windows Vista
Updates to AXIS 2.0 (support .NET clients)
Assured Services for SIP Line side devices
- MLPP support for 99xx/89xx SIP phones and 3rd party SIP Phone
- TLS connections for 3rd party SIP phones
LDAP Enhancements
Custom User Fields
- Existing LDAP agreements sync 13 default attributes
- LDAP agreements will allow 5 Custom User fields
- Custom User Fields are common across all sync agreements
- Custom User Fields updated on 1 agreement are synched across all agreements
- Attribute will be validated at save time
- Error message thrown when saving and the attribute does not exist
LDAP and Manual User Support
Prior to CUCM 9.0
- Enabling LDAP sync would prohibit adding local users
- End user to be used by CUCM must be defined on AD and synched
- Extra users could trigger extra CAL’s on the MS AD
With CUCM 9.0
- Administrator can have both LDAP sync users and locally defined users
- Ability to modify local users and roles assigned to LDAP users
- Deleting LDAP synch will mark users synced for deletion (garbage collection)
- Administrator can convert an LDAP user to a local user
- User status field is used to differentiate between the Local user and LDAP Synchronized users
To convert LDAP synchronized user to the local user account:
- Check the box Convert User Account and Save changes
- After a user is converted to local CUCM user all the fields become editable
CUCM IM and Presence
Beginning with release 9.0, CUCM and CUP will start integration to be one product
- Includes common release and upgrade process
- Centralize administration
- Simplify licensing, now included as part of CUCM user licensing
- Deprecating IP Phone Messenger (IPPM) and CUPC 7.0
Through CUCM IM and Presence administration screens, configure UC Services for clients
UC Services that can be defined:
- Voice Mail
- Visual Voice Mail
- Conferencing
- Directory
- IM
- Presence
- CTI
UC Services are used to build a UC Service Profile
UC Service Profiles assigned to users:
- Licensing for the feature handled at the user level
- Home cluster specified in the user page
When migrating to CUCM 9.0, existing service profiles and configuration in CUP will be migrated
- CUCM IM and Presence uses Templates and Layouts to speed up user creation
- BAT/AXL have been updated for CUCM/CUCM IM and Presence
Cisco Presence Integration with CCM 7.x,8.x
Cisco Presence Integration with CCM
Summary steps of integrating Cisco call manager with Cisco presence
Step#1: Enable presence globally on Cisco Call manager
By default presence subscription is disabling on CCM.
System>Service parameter>Cisco Call Manager>
Search for “Inter-presence” key word and set “Allow Subscription”
Step#2: Create SIP trunk Security Profile in CCM
Special setting is required for SIP trunk which runs from CCM to Presence.
Copy “non Secure SIP Trunk Profile” to “Presence non-secure SIP trunk Profile”
Modify below parameters:
- Device security mode: Non-Secure
- Incoming Transport type: TCP+UDP
- Outgoing Transport Type: TCP
- IncomingPort 5060 (untick Enable digest authentication)
- Enable application Level Authentication UNTICK
- Accept Presence Subscription TICK
- Accept Out-of-Dialogue REFER TICK
- Accept Unsoliciliated Notification TICK
- Accept Replace header TICK
- Transforms security status UNTICK
- Save
Step#3: Add a SIP trunk now from CCM to Presence
Device>TRUNK>SIP-trunk>
Protocol = SIP
Fill below:
- Device Name : PRESENCE-TRUNK
- Description : blah
- Device Pool : DP_HQ
- Common Dev conf : None
- call classification : On-Net
- Media resource Grp : MRG_HQ
- Location : HQ_LOC
- AAR GROUP : HQ_AARG (if not using AAR leave empty)
- Packet Capture mode : None
- Packet Capture duration: 0
- MTP required : TICK
- Retry Video call as audio : TICK
- SIP information – Destination Add: 142.2.64.51
- DST is a SRV: UNTICK
- Destination port : 5060
- SIP PROFILE : Presence non-secure SIP trunk Profile
- Save
Step#4: Make your IP Phone presence capable
- Register a phone 2001 name it HQ-Phone1
- Create end user “test” and associate HQ-Phone1/2001 with the “test” user
- Make sure test user is a part of “Standard CCM End User” and “standard CTI enable”
- Make sure Primary extension “2001” is selected when you create the above “test” user
Also Make Physical phone DN2001 has “test” user associated with it. This is the last option in line 2001’s setting before “save” button. If this has not been done and you run presence diagnostic it will keep telling you that “No line appearance existed in CCM.
Step#5: Add an application user for IPPM and MOC CTI ports
This will be used by Presence server to initiate IP Phone services:
A) Go to > User Management>Application User>
- User ID : IPPM
- pass : blah
- Presence Group : Standard
- Select the Controlled devices for this feature
- Groups : Standard CCM End User
- Save
Repeat above “A” steps for MOC_USER as well. MOC_USER will be used by MOC CTI user in Presence. All users who want presence using Microsoft MOC client will be associated to this user.
Make sure all “accept” tick boxes are TICKED on MOC_USER.
B) Go to > SYSTEM>Application Server> Add NEW
Add Presence server IP address here i.e. 142.2.64.51
Step#6: Create IP Phone service URL
Go to> Device>Device Settings> IP Phone Service
- Service Name : IP PhoneMSG
- ASCII Service Name : IP PhoneMSG
- Service Description : Blah
- Service URL : http://10.50.1.15:8081/ippm/default?name=#DEVICENAME#
- Service Category : XML Service
- Service Type : Standard IP Phone Service
- Blank
- Blank
- Enable : TICK
- Save
****Then subscribe above service to HQ phone1/2001*****
Step#7: Enable presence licensing for each user
Go to> System>License>Capability Assignment>
Then Find the end user you want to assign the presence license.
Tick the user and hit <Bulk Assignment>
A new pop up window will come. Tick both check-boxes in that and save.
- Enable CUP – TICK
- Enable CUPC – TICK
That s all we needed to do on Call Manager. Now Jump on the Presence BOX.
Step#8: Presence box general configuration:
After installing basic presence, you’ll see presence post install setup screen on your web browser by typing presence Server IP address on your browser and supplying credentials to the login screen.
So you’ll see “Post Install Setup” screen with below options:
- CUCM Publisher IP address : 142.2.64.11 (default, not changeable)
- AXL User : Administrator
- Axl password: blah…
- Confirm password : blah <then hit the “NEXT”>
- Security password : blah (whatever you supplied during installation)
- Then hit the “CONFIRM” (Ignore the warning)
Finally you will get 3 options:
A) Home B) Status C) TOPOLOGY
- Click on “HOME” you’ll see you are in a new home i.e. presence main admin page.
Step#9: Upload License and Activate presence Services
- First upload the license if you haven’t done that so far.
- GO to > Cisco Unified Serviceability>>Tools>Activate services
Activate all services; it will take 2-3 minutes.
Step#10: Configure Presence
Jump straight on Presence Admin page>>Diagnostic>System Troubleshooter
Pay attention to RED crossed balls and yellow exclamation! Signs and fix them one by one.
- Under Presence Engine: Click on FIX under “no communication presence” this will take you to add presence gateway:
Add NEW>
Presence Gateway type : CUCM
description : blah
Presence Gateway: 142.2.64.11 ← CCM IP
Double check the settings under below menus:
- SYSTEM> CCM Publisher : Check all parameter under this
- SYSTEM> Application Listener>Default class SIP TCP Listener (make sure its what you have defined in the SIP trunk on CCM – transport method TCP or UDP, both should have the same protocol/port) we are using:
Protocol = TCP
PORT = 5060 - SYSTEM> Security>INCOMING ACL
Add NEW> description=blah/all address pattern=all
Step#11: Tune the Presence Engine’s Service parameter (same as we do with CCM)
SYSTEM>> Service Parameter>Select active CUPS Server> Select Presence Engine
SYSTEM>> Service Parameter>Select active CUPS Server> Select UP SIP Proxy(ver 7)
- Search “Proxy Domain” and set it to : domain name (Ex. kcmcspunhjcups01.kpit.com)
- Search “Transport Preferred Order” and set it to : TCP/UDP/TLS
Step#12: Configure IP Phone Messenger on Presence server
Application>IP Phone> Setting
- IPPM Application Status : ON
- Application user Name : IPPMSG (created in step 3A)
- Application Password: blah…
- confirm password : Blah
- Max Instant message : 25 default
- Subscription timeout : 3400 default (3600 in ver 7)
- Publish timeout : 3600 default
Hit “SAVE”
Step#13: Select a SIP trunk between Presence to CCM
Tell presence which SIP trunk should be used for pumping calls to CCM.
Presence>>Setting>
- CUP CVP Support : UNTICK
- MAX Contact List Size : 200
- Enable Instant messaging : TICK
- Enable SIP Publish on CUCM TICK
- CUCM SIP Publish Trunk : <Select_Your_Trunk><– A MUST
Don’t forget to save after above. Above SIP trunk will be automatically listed in above “5”. This we is the one we created on CCM.
Step#14: Set TFTP address for IP COMMUNICATOR Clients
Application>Unified IP Personal Communicator>Settings
- Proxy Listener : Default Cisco SIP proxy TCP Listener
- Primary TFTP : 142.2.64.11 (CCM pub tftp)
- Backup TFTP : 142.2.64.12 (sub tftp) or whatever
LDAP – if you are using LDAP put LDAP parameters there. Else disable it.
Step#15: For MOC client define CTI Gateway
Application>>CUCM CTI Gateway>Settings
- Application Status : ON
- Application Username : MOC_USER (make sure its created on CCM as app user)
- Application Password : blah
- Confirmed Password : blah
- CUCM Address : 142.2.64.11 (CCM address)
Now time to run the Presence troubleshooter again. This will tell you what’s remaining and how to fix it. Once those are done, activate the presence and other services. Still remaining:
- MOC integration
- Creating users and testing presence
- Voicemail integration with Presence
UCCX HIGH AVAILABILTY
UCCX HIGH AVAILABILTY
Step 1 Power ON the Secondary Server and start the services.
Step 2 Upload HA license to Publisher.
System > License Information > Add License.
Step 3 Add new server to the cluster.
System > Server>Add New.
Step 4 Select Network Deployment Type – WAN/LAN
System > System Parameters.
Step 5 Select Failover Server.
Cisco Unified CCX Serviceability>Tools>Service parameters>ALPHAUCCX>Cisco AMC Service>Failover collector>
Step 6 Check the DB replication status for the data stores.
Cisco Unified CCX Serviceability>Tools > Data store Control Center > Replication Servers
Step 7 Create CTI ports for Secondary Server.
Step 8 Reboot the Servers.
Cisco Nexus 1000V Webinar Training Video’s
| Nexus 1000V Webinar Training Videos | |
| Nexus 1000V Family Overview and Update | |
| Virtual Services (VSG, vWAAS, vNAM) | |
| Virtual Security Gateway Introduction | |
| Journey to the Cloud w/ N1KV: vCloud Director & Long Distance vMotion | |
| Secure VDI with Nexus1000V & VSG | |
| Nexus 1000V v1.4 New Features and Installation/Upgrade Overview | |
| Nexus1010 Overview & Best Practices | |
| Virtual Security Gateway Technical Overview | |
| Nexus 1000V Key Features Overview | |
| Nexus 1000V Troubleshooting | |
| Nexus 1000V Web Site | |
| Nexus 1000V Webinars | |
| Nexus 1000V and VMware vCloud Director Whitepaper | |
| Nexus 1000V and VMware View Cisco Validated Design | |
| Cisco Virtual Experience Infrastructure Configuration Guide (including Nexus 1000V) | |
| Virtualize DMZ Whitepaper | |
| Nexus 1000V Community | |
| Cisco Nexus 1000V Virtual Switch Software Demo Video | |
| VMware and Cisco Accelerate Virtual Machine Deployments | |
| Cisco Nexus 1010 Virtual Services Appliance | |
| Cisco Nexus 1000V Network Analysis Module Virtual Service Blade 4.2.1N | |
| Cisco Nexus 1000V Series Switches | |
| Cisco Nexus 1000V Series Switches Video Data Sheet | |
| Cisco Virtual Network Management Center | |
| Cisco Virtual Security Gateway for Cisco Nexus 1000V Series Switches | |
| Cisco Virtualization Experience Infrastructure (VXI) Configuration Guide | |
| Cisco Nexus 1000V MIB Quick Reference | |
| Cisco Nexus 1000V Series Switches Deployment Guide Version 2 | |
| Best Practices in Deploying Cisco Nexus 1000V Series Switches on Cisco UCS B and C Series Cisco UCS Manager Servers | |
| Cisco Nexus 1000V Command Reference, Release 4.2(1)SV1(4) | |
| Cisco Nexus 1000V Installation Screencasts | |
| The following screencasts are available to assist you in the installation of Release 4.2(1) SV1(4) of the Cisco Nexus 1000V. | |
| Understanding Cisco Nexus 1000V and VMware Software Version Compatibility | |
| Video | This screencast introduces and explains the use of the Host Software Version Compatibility table in the Cisco Nexus 1000V and VMware Compatibility Informationdocument provided for each release. Given the VMware host ESX or ESXi software version, the compatibility table shows the appropriate Virtual Ethernet Module (VEM) installation files and the minimum required software versions of the VMware vCenter Server, the vCenter Update Manager, and the vSphere CLI. The screencast also shows how to determine the software version of various components and how to download update software. |
| Installing a Redundant Pair of VSMs from an OVA file Using the Installer Application | |
| Video | This screencast shows how to install a redundant pair of VSMs in an HA configuration from an OVA file using the Installer Application. |
| Installing the VEM using the VUM [two parts] | |
| VideoVideo | Part 1 of the screencast shows you how to install the VEM on an ESX host using the VUM.Part 2 of the screencast shows you how to troubleshoot and verify the installation. |
| Installing the VEM using the vSphere CLI | |
| Video | This screencast shows how to install the VEM on an ESX host using the VMware vSphere CLI. |
| Cisco Nexus 1000V Upgrade Screencasts | |
| The following screencasts are available to assist you in upgrading the Cisco Nexus 1000V to Release 4.2(1) SV1(4). We recommend that you view these screencasts and perform the procedures in the order shown. | |
| Understanding Cisco Nexus 1000V and VMware Software Version Compatibility | |
| Video | This screencast introduces and explains the use of the Host Software Version Compatibility table in the Cisco Nexus 1000V and VMware Compatibility Informationdocument provided for each release. Given the VMware host ESX or ESXi software version, the compatibility table shows the appropriate Virtual Ethernet Module (VEM) installation files and the minimum required software versions of the VMware vCenter Server, the vCenter Update Manager, and the vSphere CLI. The screencast also shows how to determine the software version of various components and how to download update software. |
| Understanding the Upgrade Process for the Cisco Nexus 1000V Release 4.2(1) SV1(4) | |
| Video | This screencast provides an overview of the steps required to update your VMware infrastructure for a non-disruptive upgrade, and to update your VEMs and VSMs to Cisco Nexus 1000V Release 4.2(1) SV1(4). |
| Upgrading the VMware vCenter Update Manager to Release 4.0 Update 1 Patch 2 | |
| Video | This screencast shows how to upgrade the VMware vCenter Update Manager (VUM) to the minimum required version for the upgrade to Cisco Nexus 1000V Release 4.2(1) SV1(4). |
| Upgrading the Cisco Nexus 1000V from 4.0(4) SV1(3, 3a, or 3b) to 4.2(1) SV1(4) [three parts] | |
| This three-part video shows you how to upgrade your Virtual Ethernet Modules (VEMs) and Virtual Supervisor Modules (VSMs) to Cisco Nexus 1000V Release 4.2(1)SV1(4). | |
| Video | Part 1 of the screencast describes the process, lists the prerequisites, and shows how to download the required software. |
| Video | Part 2 of the screencast shows you how to upgrade the VEMs. |
| Video | Part 3 of the screencast shows you how to upgrade the Virtual Supervisor Modules (VSMs). |
| Upgrading the Cisco Nexus 1000V from VMware Release 4.0 to 4.1 [three parts] | |
| This screencast shows how to upgrade your vCenter Server, vCenter Update Manager, and vSphere CLI from VMware Release 4.0 to Release 4.1. | |
| Video | Part 1 describes how to check software compatibility and how to upgrade the vCenter Server. |
| Video | Part 2 describes how to upgrade the VUM. |
| Video | Part 3 describes how to upgrade the hosts. |
CCNP Voice free Training
All About Extension mobility
Introduction
This document describes the common problems in Extension Mobility.
Error :- Host not found
Resolution:-
- Check that the Cisco Tomcat service is running by choosing Cisco Unified Serviceability > Tools > Control Center—Network Services
- If you have changed the ip address on service URL then click on “Update subscriptions“ (Device > Device Settings > Phone Services >IP Phone Services Configuration).and resubscribe each phone to which the wrong service was subscribed.
Error:- You can’t see the EM feature after hitting the services button
Resolution:-
-Verify that you have configured the Extension Mobility service
-Verify the service URL is correct
– Start/Restart the EM services on each node you are running.
Error:- You can’t log in/out of the EM feature but you can see it after pressing the services button
Resolution:-
This error comes when you haven’t enabled the extension mobility , subscribed the phones/device profiles to the service as needed and haven’t associated user to a device profile.
Error:- To set up speed dials and other services from your phone, please goto https://x.x.x.x:8443/ccmuser/showHome.do
Resolution:-
The above error comes when you haven’t subscribed the phone or device profile to the EM profile. Once this is done you should be able to see the EM profile and log in correctly.
Error:-After a user logs out and the phone reverts to the default device profile, the user finds that the phone services are no longer available.
Resolution:-
1. Check the Enterprise Parameters to make sure that the Synchronization Between Auto Device Profile and Phone Configuration is set to True.
2. Subscribe the phone to the Cisco Extension Mobility service.
Error:-After performing a login or logout, the user finds that the phone resets instead of restarting.
Resolution:-
- Locale change may provide the basis for reset.
- If the User Locale that is associated with the login user or profile is not the same as the locale or device, after a successful login, the phone will perform a restart that is followed by a reset. This occurs because the phone configuration file is being rebuilt.
Error[201]-Authentication error
Resolution:-
The user should check that the correct UserID and PIN were entered; the user should check with the system administrator that the UserID and PIN are correct.
Error [22]-Dev.logon disabled
Resolution:-
Make sure that you have chosen “Enable Extension Mobility” check box on the Phone Configuration window.
Error [205]-User Profile Absent
Resolution:-
Make sure that you have associated a Device Profile to the user.
Error [208]-EMService Conn. error
Resolution:-
Verify that the Cisco Extension Mobility service is running by choosing Cisco Unified Serviceability > Tools > Control Center—Feature Services
Error [25]-User logged in elsewhere
Resolution:-
Check whether the user is logged in to another phone. If multiple logins need to be allowed, ensure the Multiple Login Behavior service parameter is set to Multiple Logins Allowed
Error:- Http Error [503]
Resolution:-
If you get this error when Services button is pressed, check that the Cisco Communications Manager Cisco IP Phone Services service.
- If you get this error when you select Extension Mobility service, check that the Cisco Extension Mobility Application service is running by choosing Cisco Unified Serviceability > Tools > Control Center—Network Services.
Error:- [202]-Blank userid or pin
Resolution:-
Enter a valid userid and PIN.
Error:- [26]- Busy, please try again
Resolution:-
- Check whether the number of concurrent login/logout requests is greater than the Maximum Concurrent requests service parameter. If so, lower the number of concurrent requests.
- To verify the number of concurrent login/logout requests, use Cisco Unified Communications Manager Cisco Unified Real-Time Monitoring Tool to view the Requests In Progress counter in the Extension Mobility object.
Error:-[6]-Database Error
Resolution:-
- Check whether a large number of requests exists
- If large number of requests exists, the Requests In Progress counter in the Extension Mobility object counter specifies a high value. If the requests are rejected due to large number of concurrent requests, the Requests Throttled counter also specifies a high value.
Error:- [207]-Device Name Empty
OR
Error:- XML Error [4] Parse Error
Resolution:-
Check that the URL that is configured for Cisco Extension Mobility is correct and there should be no space in between.
Error:- 8945 phone does not show EM service
Resolution:- Set service provisioning to default or internal. Refer Bug CSCtx70127
Distributed Voice and VXML Gateway Design with CVP SIP Deployments
Introduction
This document discusses solutions to distributed VXML and Voice GW deployments when Ingress-GW and VXML-GW are NOT residing on same router in SIP call flow scenarios.
When the VoiceXML and voice gateway functions reside at the same branch location but on separate devices, an IPCC design engineer should make sure that the VRU leg is sent to the local VoiceXML GW. There are two ways to ensure that the calls are handled within the branch and not sent across the WAN to a different VoiceXML gateway.
Two possible solutions
- Configure Unified ICM with multiple Customers instances, one per location
- Since this is not a scalable solution and also cannot be used if VRU is Type10 so we will not discuss it here.
- Configure Unified CVP with setTransferLabel or SigDigits feature
- If a customer has VoiceXML Gateway and Voice Gateway configured on the same router, then you should use CVP Call Server’s “setTransferLabel” mechanism which applies only to co-resident VoiceXML and Voice Gateway configurations.
- If a customer has VoiceXML Gateway and Voice Gateway configured on different routers, then you should use CVP Call Server’s “SigDigits” mechanishm which applies to distributed VoiceXML and Voice Gateway configurations.
Unified CVP SigDigits Feature
The SigDigits feature in Unified CVP allows you to use the dial plan on the SIP Proxy to route calls to the correct site. When the call arrives at an ingress gateway, the gateway will prepend digits before sending the call to Unified CVP. Those prepended digits are unique to that site from a dial-plan perspective. When the call arrives at Unified CVP, Unified CVP will strip the prepended digits and store them in memory, resulting in the original DID on which the call arrived. Unified CVP then notifies Unified ICM of the call arrival using the original DID, which matches a Dialed Number in Unified ICM.
Example
Call arrives at the Toronto voice gateway (TOR-V-GW) with a DID of 416-431-1000. The Toronto Voice Gateway will add 821 as a site code and will send it to central SIP Proxy server in Chicago. The Chicago SIP Proxy will send it to Chicago CVP server. So Chicago CVP Server will receive 821.416-431-1000. On the Chicago CVP server we have “SigDigits=3″ configured. Chicago CVP server will strip 821 and will send 416-431-1000 as a dialed number to ICM
Unified ICM Returns a Label
When Unified ICM returns a label to Unified CVP in order to transfer the call to a VoiceXML gateway for IVR treatment or to transfer the call to an agent phone, Unified CVP will prepend the digits that it stored in memory before initiating the transfer. The dial plan in the SIP Proxy must be configured with the prepended digits in such a way to ensure that calls with a certain prepended digit string are sent to specific VoiceXML gateways.
Example
ICM returns 416-431-2000 as label to queue the call at the edge Toronto VoiceXML gateway (TOR-VXML-GW). ICM will add 821 and will send the call to SIP Proxy server. Chicago SIP Proxy server will receive 821.416-431-2000. Based on the 821 site code, it will send call to TOR-VXML-GW for queuing.
How to turn on SipDigits Feature
To turn on this feature and specify how many significant digits should be stripped is to change the sip.SigDigits = X field in sip.properties file in all CVP Call Servers. Where X is the number of digits to be stripped.
SIP RingTone and Error Services
There is one caveat that SigDigits feature does not cover the 91919191 (RingTone) and 92929292 (Error) DNs for those services. What this means is that once the agent becomes available, CVP needs to pull the call that is queued at the edge on the VXML-GW and connect the caller to the agent. During this transition, CVP needs to play a ringback tone to the PSTN caller. CVP does that by initiating a SIP call (CVP sends a SIP invite) towards the VXML-GW by dialing 91919191 to play a rintone back.
VXML-GW matches this 91919191 on an incoming SIP VoIP dial-peer and sends ringback.wav file to the ingress Voice GW. This file is being stored in the VXML-GW and is benign sent to the ingress GW. So there will be g711 traffic will flow for some duration.
H.323 Call Flow for CVP Comprehensive Deployment Model
Introduction
This document discusses very high level and brief over view of H.323 Call Flow in CVP Comprehensive Deployment Model.
The PSTN call could arrive using a traditional T1/E1 PRI trunk or using some IP based trunk potentially a SIP trunk. The PSTN call will be terminated on a Cisco voice gateway in case of T1/E1 PRI trunk for example. And from the voice gateway it could be sent to a H.323 gatekeeper or directly to the CVP depending on the deployment.
PSTN----T1/E1-----VGW----GK----->CVP
OR
PSTN----T1/E1-----VGW----------->CVP
In case of SIP trunk, it will be terminated on a Cisco Unified Border Element (also called Session Border Controller). From here it could be sent to a Cisco Unified Presence Server (CUPS) SIP Proxy Server or directly to the CVP depending on the deployment.
PSTN----SIP------CUBE----CUPS-SIPProxy----->CVP
OR
PSTN----SIP------CUBE---------------------->CVP
Call Flow
1. Public switched telephone network (PSTN) call arrives at the ingress voice gateway (VGW).
2. Ingress VGW delivers the call to CVP (with H.323).
3. CVP informs ICM of the new call. This leg is the switch leg of the call. ICM routing script instructs CVP to perform queuing or self-service application (using CVP studio).
CVP-----Switch-Leg----->CUICM
4. CVP transfers the call to the Voice Extensible Markup Language (VoiceXML) gateway for VRU leg operation to perform prompt/queuing or self-service. VoiceXML gateway fetches VoiceXML pages from the CVP Call Server and/or CVP VoiceXML Server.
CVP-----VRU-Leg-------->VXML-GW
5. After the self-service session or queuing, eventually ICM sends an agent label (directory number) to CVP to transfer the call to the agent.
CUICM-----agent-label------>CVP
6. CVP tears down the VRU leg towards the VoiceXML gateway and transfers the call to the agent through IP switching by performing the call setup (H.323) to the destination IP device (egress VGW or Communications Manager, etc.) and redirecting the switch leg media stream to the agent destination. CVP remains in the call signaling path for subsequent transfers as needed and the media flows from the ingress VGW to the destination IP endpoint.
SIP Call Flow with CVP Comprehensive Model
Introduction
This documents aims to provide detailed SIP CVP comprehensive Call Flow with the debugs captured from the CVP logs and IOS/VXML Gateways
Network Setup
The setup is very simple to demonstrate the SIP call flow.
- A call comes in from PSTN Phone and goes to the ingress gateway
- Ingress gateway is also acting as VXML Gateway for this setup
- Ingress gateway sends the call to CUP SIP Proxy
- CUP SIP Proxy sends the call to the CVP Call Server
- CVP Call Server will send the call to ICM
- Agents are connected to the CUCM
Following script is being used (Notice that Microapps are being used and no Call Studio script is being used in this setup)
ICM Script Flow
- Call comes in and hit Start
- Some variables are being set (HTTP Media Server IP Address, Directory Name for the stored media files, en-us locale, input type being set it digits etc.)
- Then call is being sent to VRU which VXML-GW
- VXML instructions are being sent to the VXML-GW
- Save the digits into a variable
- Play those digits back to the caller
- Set LAA (Longest Available Agent) agent selection algorithm
- Wait in the queue for agent to become available
- During this time play a hold music to the caller in the loop
In the following section the details will be discussed step by step
(1) Call Comes in from the PSTN
PSTNph---PSTN----Ingress-gw----->CUPS
Call matches an incoming pots dial-peer for the destination number. It is important to configure cvp-survivability service under the POTS dial-peer. If this service is not configured on the incoming pots dial-peer, the ingress gateway will not be able to communicate with the CVP Call Server and might receive “SIP/2.0 503 Service Unavailable” message from the CVP Call Server.
dial-peer voice 1 pots service cvp-survivability incominca-called-number 5417641400 direct-inward-dial
In the event of some critical CVP application failure, survivability.tcl script will attempt to recover and smoothly disconnect the caller after playing critical_error.wav file from Ingress-GW’s flash. It is very important to have this script because this script also plays pleasewait.wav and holdmusic.wav files from flash depending on situation.
Call Matches following outbound sip voip dial-peer on the ingress-gw
dial-peer voice 1400 voip translation-profile incoming block preference 1 max-conn 2 destination-pattern 5417641400 session protocol sipv2 session target ipv4:10.4.33.97 ## CUPS SIP PROXY SERVER IP ADDRESS dtmf-relay rtp-nte codec g711ulaw ip qos dscp cs3 signaling no vad
CUPS load balance the call because there are static routes configured in it and sends call to CVP Call Server
Destination VP Server IP Address Priority Weight Protocol 5417641400 10.4.33.131 5060 1 1 UDP 5417641400 10.4.33.132 5060 1 1 UDP 5417641400 10.4.33.133 5060 1 1 UDP
(2) CUPS —-> CVP Server
Call lands to the CVP Call SERVER and in the CVP Call Server log you could see following
[CVP Server Logs]
3052: 10.4.33.131: Mar 13 2008 14:34:39.703 -0700: %CVP_7_0_ICM-7-CALL: {Thrd=Pool:ICM[1450]}
CALLGUID = 8B82AD85F07B11DC80250013192D1650, DLGID = 21 [SIP_LEG] - Publishing ,,
[ICM_NEW_CALL],dialogueId=21, sendSeqNo=1,trunkGroupId=100,trunkNumber=0,serviceId=1,
dialedNumber=5417641400,uui=,, LEGID = 8C1C7CEE-F07B11DC-8177F66C-9B680D18,DNIS = 5417641400,ANI = 4085274003
(3) CVP Server —> CUICME via VRU-PG
CVP Server sends the call to CUICM via VRU PG. Notice that we didn’t configure the IP address of the CUICM or the VRU-PG in the CVP Call Server. CVP Call Server automatically sends the information to the CUICM’s VRU-PG, because during the CUICM configuration, we had already specified the IP addresses of our CVP Call Servers. The VRU PG will connect to the ICM Service on the CVP Call Server. Once that TCP socket is established, the CVP acting as the routing client functionality becomes active in ICM and CVP will communicate with ICM/PG over that socket.
(4) CUICM [Runs Routing Script]—>Generates Label+Correlation-ID
When call arrives at CUICM, it causes Unified ICM to run a routing script. In the routing script there is a node called SendToVRU node (Remember: VRU in our case is VXML-GW and SendToVRU node is added right after setting the basic variables). The SendToVRU is what triggers ICM to transfer the call to the VXML GW (which is the VRU). The routing script will typically initiate a transfer of the call to a VoiceXML Gateway port (due to SendToVRU node) via the SIP Service. You could see following in the router process windows on the CUICM Server
[CUICME Router Logs] 14:51:07 Trace: CT_SL_Timer(56)(Init): CT(5000,PreSales_CT), Threshold(20 + 2). 14:51:07 Trace: Correlation id for dialog (23 x 0 : 0 0) is (44). 14:51:07 Trace: Dialog (23 x 44 : 0 0) transfer label = 5417641401
As you can see from above that ICM returns a VRU label 5417641401+correlation-id (44) back to CVP Call Server (Remember CVP Server was the routing-client).You can see the same information on the CVP Call Server logs that a call goes to ICM and ICM returns a label back to the CVP Call Server (Which is the routing-client for ICM). This correlation-id (which is 44 in our case ) will be appended at the end of the label.
[CVP Call Server Logs]
3053: 10.4.33.131: Mar 13 2008 14:34:39.718 -0700: %CVP_7_0_ICM-7-CALL: {Thrd=Pool:ICM[1451]}
CALLGUID = 8B82AD85F07B11DC80250013192D1650, DLGID = 21 [SIP_LEG] - Processing ,,
[ICM_TEMPORARY_CONNECT], dialogueId=21,sendSeqNo=1, label=5417641401, correlationId=44,,
LEGID = 8C1C7CEE-F07B11DC-8177F66C-9B680D18, DNIS = 5417641400, ANI = 4085274003
Now CVP Call Server will send this VRU label (5417641401+44) to the VXML GW (It is more accurate to say that CVP transfers the call TO the VXML GW, with the label+correlation ID as the destination phone number). In our case, it is only coincidence that the VXML GW is the same as the ingress GW. The “transfer” that CVP does is not a typical one either, because CVP stays in the call path (whereas usually the transferor drops out of the call path).
In reality CVP is setting up a NEW call to the VXML GW and is shuffling the SDP from the ingress GW to the VXML GW in order to connect the media directly (similar to CUCM or CUBE in flow-around mode). CVP stays in the signaling path so that it can retain call control.
[VXML-GW Debugs]
debug voip application vxml calling Number=sip:4085274003@10.4.33.131:5060,(Calling Name=)(TON=National, NPI=ISDN, Screening=User, Passed, Presentation=Allowed), Called Number=sip:541764140144@10.4.33.1:5060;transport=tcp(TON=Unknown, NPI=Unknown)
This label matches 1401 voip dial-peer in the VXML-GW and invokes bootstrap VXML application.
dial-peer voice 1401 voip
translation-profile incoming block service bootstrap session protocol sipv2 incoming called-number 5417641401T ## T is used to match the correlation-id dtmf-relay rtp-nte codec g711ulaw ip qos dscp cs3 signaling no vad
The bootstrap VXML application tells the CVP that it is a new call and CVP then sends the same label (5417641401+44) back to ICM. Once ICM sees its own generated label, this actually completes the loop and ICM at this point knows that there is a VXML Gateway ready to accept the instructions.
(5) CUICM—> RunExternalScript node
The steps below are the RunExternalScript nodes that tell CVP what VXML pages to send to the VXML gateway (play prompt, get digits, etc). CUICM execute the script instruction called “RunExternalScript”. This basically tells CVP that IVR related instructions are coming. CUICM then sends instructions like for example “Get4Digits”. CVP sends this instruction to VXML-GW to play the prompt to the caller. When caller enters the digit, ICM stores it in its variable [for example Call.CallerEnteredDigits variable].
[VXML-GW Debugs] 063686: Mar 13 18:25:14.383 PST: //404/vapp_digit_collection_done: digits [5432], status [0], pattern [v0] 063687: Mar 13 18:25:14.383 PST: //404/vxml_digit_collection_done: vxmlp 6A6D1EA4 status 0 async_status 200000000 063688: Mar 13 18:25:14.383 PST: //404/vxml_digit_collection_done: digits (5432)
ICM Script then instructs CVP to play the prompts back to the user on the PSTN side. For simplicity we can say that in order to do that CVP makes an inbound call to the VXML gateway by dialing 987654 and plays the prompt. But in reality we wouldn’t say that CVP makes an inbound call to the VXML gateway (since that already happened above). The 987654 is actually a transfer instruction that was received via VXML from CVP, the only reason it exists is because it is a workaround for some problem with playing media files and retaining the vxml session.
[VXML-GW DEBUGS] 063767: Mar 13 18:25:14.407 PST: //404/vxml_item_attrs_proc: name=mycall URI(abs):phone://987654 scheme=phone host=987654 bridge=1 connecttimeout=0 maxtime=0 desttype=-1 destplan=-1 anitype=-1 aniplan=-1 anipi=-1, anisi=-1 rdntype=-1 rdnplan=-1 rdnpi=-1, rdnsi=-1, redirectreason=-1 063779: Mar 13 18:25:14.407 PST: //404/vapp_media_play: prompt=http://10.4.33.130/en-us/sys/5.wav: 063780: Mar 13 18:25:14.407 PST: //404/vapp_media_play: prompt=http://10.4.33.130/en-us/sys/4.wav: 063781: Mar 13 18:25:14.407 PST: //404/vapp_media_play: prompt=http://10.4.33.130/en-us/sys/3.wav: 063782: Mar 13 18:25:14.407 PST: //404/vapp_media_play: prompt=http://10.4.33.130/en-us/sys/2.wav:
(6) CUICM—->Agent
- When an agent becomes available, ICM instructs CVP to transfer the call to the agent.
- CVP will disconnect the call to the VXML GW (SIP BYE), will send a re-INVITE back to the ingress gateway to stop media, and will send a new INVITE to the agent phone and to the ringtone service below.
- When the ringtone service answers, a re-INVITE is sent to the ingress gateway with the VXML GW’s SDP in order to establish the media stream for the ringback.
- Once the Agent answers the phone, CVP disconnects the call to the VXML GW (with BYE & re-INVITE same as before), and then connects the media stream from the ingress gateway to the agent phone.
- In this entire call flow, there have been 4 distinct SIP phone calls that are separate from each other:
- ingress gateway to CVP;
- CVP to VXML GW (IVR);
- CVP to VXML GW (ringtone);
- CVP to Agent.
- Each phone call, from a SIP perspective, is completely separate from the others, because CVP is a B2BUA and not a proxy.
- Whenever CVP does a transfer, it disconnects the previous destination that the caller was connected to and connects them to the new destination.
- Thus, CVP acts as a pivot point for the call.
- Since CVP is under control of ICM, that is what makes CVP so powerful – the ability to control the call from very first component that received the call. This is in contrast to a typical PBX/ACD (including CUCM) where the transfers are tromboned through every component that was involved in the call, tying up additional DS0’s or memory.
- In a SIP call flow, during the time when CUICM is transferring call over to the agent, there is a need to play ringtone back to the caller. And also if in case there is an error during transfer, CVP should be able to play error tone back to the caller. These tones will be generated by playing a .wav file off of the VXML gateway flash.
- In the CVP, there are two parameters under SIP section. These are the DNs that CVP sends to VXML GW when there is a need to generate the ringtone or error tone.
- When these numbers reach the VXML GW, it matches with an incoming voip dial-peer and VXML GW starts the respective service/app
dial-peer voice 9191 voip service ringtone incoming called-number 91919191 dtmf-relay rtp-nte h245-signal h245-alphanumeric codec g711ulaw session protocol sipv2 no vad ! dial-peer voice 9292 voip service cvperror incoming called-number 92929292 dtmf-relay rtp-nte h245-signal h245-alphanumeric codec g711ulaw session protocol sipv2 no vad
- You can see the VXML-GW playing the file by noticing the following debugs
[Debugs VXM GW] 062151: Mar 13 18:14:12.483 PST: //383/tcl_MediaObjCmd: media play leg_incoming flash:ringback.wav 062152: Mar 13 18:14:12.483 PST: //383/tcl_MediaPlayObjCmd: play leg_incoming flash:ringback.wav
NOTE: Ignore the timestamp in the debug messages. These debugs were captured by making multiple calls over a period of time
Different Gateway Applications
bootstrap.tcl
The script extracts required parameters and then hands off the call to the boot strap VXML service named “new-call” which loads the bootstrap.vxml file. This VXML page then submits a new call HTTP request to the Customer Voice Portal (CVP) IVR Service which kicks off a sequence of VXML communications between the VXML Gateway and the CVP IVR Service, commonly called “MicroApps”. For SIP calls, this script extracts Call GUID, Call Server URL, and DNIS. Call Server host is extracted from the App-Info header. For H.323 calls, Call GUID and DNIS are extracted. Call Server is also extracted from the call data. For both SIP and H.323 calls, the Call GUID is normalized in base16, 35 char length hex format as follows(not base10, 43 char length):
HHHHHHHH-HHHHHHHH-HHHHHHHH-HHHHHHHH
bootstrap.vxml
The VXML-GW sends a new call request to the Customer Voice Portal (CVP) IVR Service which kicks off a sequence of VXML communications between the VXML Gateway and the CVP IVR Service, commonly called “MicroApps”. Any HTTP errors, or fetch errors (7 second timeout), will handoff to recovery.vxml in flash and handoff.tcl in flash.
Handoff.tcl
Handoff.tcl has the sole job of disconnecting a call with a code an ISDN Q.850 code of 38.
survivablity.tcl
This service should be placed on the ingress-gw on the incoming pots dial-peer that is destined for CVP. In the event of critical CVP application errors or a WAN failure that would normally disconnect the caller, this script allows the gateway to attempt a transfer to some alternate location after the failure occurs instead of disconnecting the caller. In the event that the call cannot be transfered to an alternate agent, the script will play a “call-back-later” message and disconnect.
By VKN
Bsoft bangalore
