DrVoIP CISCO CIPTV2 CCNP Collaboration 300-075 Study notes!

OverView of 300-075 Content

Like many other working VoIP Engineers, I have had to upgrade my CCNP yet again. The first time was when CISCO changed from CCVP to CCNP Voice. Now we have to convert from CCNP Voice to CCNP Collaboration. The good news is, if you have a CCNP voice you only need to pass this one test, the CISCO 300-075 CIPTV2! The test however, is remarkably difficult as the availability of study materials is limited. The available CISCO Press book “Implementing IP Telephony and Video Foundation Learning Guide” is just not going to get the job done! Certainly you should digest the book but do not expect to pass this exam with only the material contained in that book. The book is useful for at least highlighting the areas you need to study:

(a) Expressway Firewall Traversal Configuration;
(b) VCS Control;
(c) All things Mobility (Device Mobility, Extension Mobility and Mobile Voice Access);
(d) SRST;
(e) QOS for Video including RSVP options;
(f) SAF and CCD; ILS and GDPR
(g) LRG, AAR and TEHO;
(h) Translation Patterns and Voice Translation Rules;

All these areas were covered in the exam, so be prepared. The good news is I got an 820 when i took the test the first time. The bad news is that passing was 860! There was once question on Call Clearing codes that I had not idea how it got in this test, but none the less you might want to review  that material in the referenced URL

300-075 Practice Tests and Dumps

If you are just looking for a cheat sheet, I really cant help you as most of the stuff on the Internet is riddled with errors.  As near as I can figure it, all the practice tests and dumps on the net have the same source and are packed for marketing under different names.   I do find that they are useful for getting some focus on the exam content, but you need to look up every question and find a reference that supports the answer the dump indicates is correct.   I found many errors through study and research!  At the end of the day, you either know this stuff or your do not know this stuff.  Here is a list of sites that have practice materials available for no charge:


Real VoIP Engineer Study Sites

I found a few sites that are written by other engineers who are sharing their study notes as I am doing here.  Both of these are excellent examples created by other Engineers who were also cramming for this test.



https://ccieme.wordpress.com. (really great content)!

DrVoIP Study Notes on 300-075

In going through all the study materials, I noted my references and I offer them up here for others who may be following this path to certification.  The questions represent practice tests from the above sources in which they all had different answers to the same question.  So in keeping with my commitment to actually learn and digest this material, I dug deep to find CISCO references to support the answers or to sort through the wrong answer and find the correct answer.   As with all CISCO tests you need to carefully read the question and put the answers within the context of the subject they are asking about.  Many times there will be two very good answers, but only one is the one CISCO wants you to select to get the points for a correct answer!

1 – The HQ Cisco Unified Communications Manager has been configured for end-to-end RSVP. The BR Cisco Unified Communications Manager has been configured for local RSVP.
RSVP between the locations assigned to the IP phones and SIP trunks at each site are configured with mandatory RSVP. When a call is placed from the IP phone at HQ to the BR phone at the BR site, which statement is true?https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/8_6_1/ccmsys/accm-861-cm/a02rsvp.pdf

End-to-End RSVP

End-to-end RSVP configuration is available if the clusters are connected by a SIP trunk. End-to-end RSVP uses RSVP on the entire connection between the end points, and uses only one RSVP agent per cluster.

Consider the following scenario:

endpoint A — agentA — ICT1 — ICT2 — agentB — endpoint B

where A specifies an endpoint in cluster 1, B specifies an endpoint in cluster 2, ICT1 and ICT2 specify the intercluster trunks within clusters 1 and 2, and the RSVP Agents associate with the respective end points.

In this scenario, Cisco Unified Communications Manager establishes an end-to-end RSVP connection between agentA and agentB.

Configuring End-to-End RSVP Over a SIP Trunk

RSVP configuration on a SIP trunk is determined by the SIP profile that is applied to the trunk. To enable end-to-end RSVP on a SIP trunk, configure the trunk’s SIP profile as follows:

  • From the RSVP Over SIP drop-down list, choose E2E.
  • Set the Fall back to local RSVP field to your preference.
  • From the SIP Rel1XX Options drop-down list, choose an option other than Disabled.


2 – Company X has deployed a VCS Control with a local zone and a traversal client zone. To facilitate external calls, VCS Expressway is deployed and traversal server zone is set up there. Video endpoints inside Company X have registered, but are unable to receive calls from outside endpoints. Which option could be the cause of this issue?

Which Three Devices Support the SAF Call Control Discover Protocol?



CUCM, CUBE, CME, IOS Gateway, CUCM CME are CCD SAF clients!

3 – Which two steps must you take when implementing TEHO in your environment?


4 – Which two commands verify Cisco IP Phone registration? (Choose two.) . https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/troubleshooting/guide/ts_phreg.html

For SCCP phones: Use the show ephone registered command to display the status of registered SCCP phones.

For SIP phones: Use the show voice register statistics command to display statistics associated with the registration event.  Use this command to display all the SIP endpoints currently registered with the contact address.
Router# show sip-ua status registrar

5 – A pre sales engineer is working on a quote for a major customer and must evaluate how
many Cisco VCS Expressway traversal call licenses for which to plan. Calls to and from
which three routes must the engineer include in the tally? (Choose three.)    or said another way

(When do calls on a VCS use a traversal call license?

  1. Any call where the VCS takes the media as well as the signaling is a traversal calland will use a traversal call license on that VCS. The following calls require the VCS to take the media, and are therefore traversal calls:
  • for a VCS Control, calls to or from a traversal server (i.e. firewall traversal calls)
  • for a VCS Expressway, calls to or from a traversal client (i.e. firewall traversal calls); traversal clients include other VCSs, gatekeepers, Border Controllers, or traversal-enabled endpoints
  • calls that are gatewayed (interworked) between H.323 and SIP on the local VCS
  • calls that are gatewayed (interworked) between IPv4 and IPv6 on the local VCS
  • for VCSs with Dual Network Interfaces enabled, calls that are inbound from one LAN port and outbound on the other
  • a SIP to SIP call when one of the participants is behind a NAT (unless both endpoints are using ICE for NAT traversal)

6 – What is the standard Layer 3 DSCP media packet value that should be set for Cisco
TelePresence endpoints?  (CS4/32) See Table 5-1  If the question is on Telepresense it is CS4/32 if it is a quation on Video then it is AF41/34


7 – Which two actions ensure that the call load from Cisco TelePresence Video
Communication Server to a Cisco Unified Communications Manager cluster is shared
across Unified CM nodes? (Choose two.)
https://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/X8-1/Cisco-VCS-Basic-Configuration-Control-with-Expressway-Deployment-Guide-X8-1.pdf  and See Table 11

8 – An engineer must resolve a call failure issue. When using RTMT, the engineer notices that
the Location Bandwidth Manager-OutOfResources counter is showing a positive value.
Which option is the cause of the call failure?

9 – An engineer is configuring URI calling within the same cluster. Which four actions must be
taken to accomplish this configuration? (Choose four.)

10 – Which two options are functionalities of subzones in  cisco vcs deployment (choose two). https://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/vcs/admin_guide/Cisco_VCS_Administrator_Guide_X7-2.pdf


Bandwidth management

The Local Zone’s subzones are used for bandwidth management. After you have set up your subzones you can apply bandwidth limits to:

n individual calls between two endpoints within the subzone
n individual calls between an endpoint within the subzone and another endpoint outside of the subzone n the total of calls to or from endpoints within the subzone

For full details of how to create and configure subzones, and apply bandwidth limitations to subzones including the Default Subzone and Traversal Subzone, see the Bandwidth control section.

Registration, authentication and media encryption policies

In addition to bandwidth management, subzones are also used to control the VCS’s registration, authentication and media encryption policies.

Apply registration, authentication, and media encryption policies
Manage bandwidth to restrict standard definition endpoints from using more than 2 Mb of bandwidth. “Subzones are used to control the bandwidth used by various parts of your network, and to control the VCS’s registration, authentication and media encryption policies”.

11 – A voice-mail product that supports only the G.711 codec is installed in headquarters.
Which action allows branch Cisco IP phones to function with voice mail while using only the G.729 codec over the WAN link to headquarters?

Much confusion as to correct answer as some report B and others report C. The trick is in the question. The all must traverse the WAN as G.729, therefore you can not transfer at the branch. You send media to the Voice Mail at HQ as G.729 and transcode remotely at HQ. this suggests that B is the correct answer. – DrVoIP.com

12 – Which two are gatekeeper-controlled trunk options that support gatekeeper call administration control? (Choose two.) https://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/4_0_1/ccmsys/a08trnk.html#wp1098346

13 – An engineer is configuring Global Dial Plan Replication and wants to prevent the local cluster from routing the Vice President number 5555555555 to the remote cluster. Which action accomplishes this task?   Create a Block Learned pattern as outlined in this reference


14 – A PSTN call arrived at the MGCP gateway. The calling number was received as
14087071222 with number set to type international. The HQ_clng__pty_CSS contains the HQ_clng_pty__Pt partition. Which caller ID is displayed on the IP phone?


15 – Analog Voice Gateway support (See Table 1)


16 – An engineer must enable video desktop sharing between a Cisco Unified Communications Manager registered video endpoint and a Cisco VCS registered video endpoint. Which protocol must be enabled in SIP profile for VCS SIP trunk on Cisco Unified Communications Manager?


At any rate, using Dumps is a high risk.  At $300 US to take this exam, getting a “money back guarantee” on a $59 practice test is not very helpful.   I passed the on the second attempt with an 860!   I can assure you that more than 50% of the questions were NOT on any dump.  Again the only real value in these dumps is to point you in a study area.  Take every question and open a text book, or CISCO reference and make sure you really understand the subject matter.   This is NOT an easy test, but if you study, you will pass it.   Good Luck!






Configuring a SIP Trunk TIE Line between CISCO CUCM and ShoreTel iPBX

Merging Systems is fun and easy?

In a world of swirling mergers and acquisitions,  IT organizations are expected to integrate the different systems so that they all work together.   In the world of  IP PBX systems, that might result in having to make a ShoreTel system play nice with a CISCO system.  Actually, both systems support SIP and though it is sometimes more of an art than a science, it can be configured and made to work.   In fact we are seeing this request a lot lately.  Not sure why, but there are a lot of ShoreTel/CISCO integrations out there in the real world!   This video cheat sheet takes a look at a real world configuration from both the ShoreTel side and the CISCO side, so there is something for everybody who has to work with either or both systems.

Quick Topology Overview

In our example we have a CISCO Version 11 deployed in France and a ShoreTel version 14.2 CPE solution deployed in several NY locations.    This will be an interesting configuration as both systems have over lapping extension numbers.  For example, both systems have the range of 4100-4199 as extension numbers.  This along with a requirement for tail end hop off or TEHO at both ends makes for an interesting configuration puzzle.  We determined to take it a step at a time and get a basic SIP  TIE line working between the two systems.  Once that was up an operational, we could then focus on the basic dial plan strategy that would enable us to resolve the extension number conflict.

We are not going to use a session boarder controller at either end.   The good news is that it will greatly simplify the configuration as the two SIP proxies will directly exchange SIP messages.   In the case of the CISCO, the SIP trunk will originate on the call manager server itself and will terminate on a ShoreTel SG appliance (one of those orange boxes for you CISCO guys) with SIP Trunk resources sufficient for the number of channels you want to set up.    The bad news is, that on the CISCO side it makes trouble shooting a bit more time consuming.  If you had a CUBE in the mix you could easily open up CCSIP Messages in the debug on the IOS device, but when you do not have IOS you need to download logs from RTMT.  On the ShoreTel side, there is the ability to do a remote wire shark capture from the HQ server diagnostic panel using the SG appliance as the end point source.   (As a VOIP engineer SIP debugging should be second nature).

To avoid the use of a SBC on either end, we have to configure the solution entirely within a private IP topology.  In this case we have a /24 network on the ShoreTel side and a network on the CISCO side.   The WAN connection is an MPLS network.

ShoreTel and CISCO dial plan strategies

CISCO does not really care about over lapping extension numbers of difference in extension number ranges.  When I say, they don’t care, I mean they have a strategy for dealing with it.   You might have a multi-site deployment as a result of a recent acquisition and you have four digit extension numbers at one site, and five digit extension numbers at a different site.  CISCO can deal with this.  ShoreTel not so much.   With ShoreTel you would have to convert the four digit site to five digits (you can expand from four to five digits,  but not five to four) if you are going to have one dial plan.  In CISCO you could actually let both sites coexist with different extension number lengths.

CISCO has a verbose dial plan strategy that expects you to create route “patterns” that when matched by dialed digits, point to a gateway or route list that contains a destination reachable by that route pattern.  In our example, we set up a dial pattern of 51.xxxx with a pre-dot discard that points to the SIP trunk TIE Line over to the ShoreTel.   The SIP Trunk configuration is relatively simple and is shown in the video below.

ShoreTel requires you to configure a Trunk Group and then put your individual trunks into the group.  These individual trunks are basically SIP channels and the video also shows this configuration.  The difference in the strategy of both systems is interesting to note.   CISCO is routing to this trunk group based on a route patter that matches dialed digits.  ShoreTel is going to want you to define both an access code and list out the OPX (off premise extension) numbers that this trunk can reach.

From a digits dialed perspective, ShoreTel is going to match the dialed digits against the list of OPX extensions to route calls over the Trunk Group that contains a matching OPX list.   Note that no access code will be required, though it will be required in the Trunk Group configuration.

SIP Trunk Group Profiles

Both systems required a reference to a SIP Profile that defines specifics of the call setup messaging.    Sometimes this is a bit more of an art than a science and it may take a bit of tweaking.   CISCO has a standard SIP Profile and an associated SIP Security profile both of which will be referenced in the SIP trunk configuration.  The only change I typically make to the SIP Profile on CISCO is to activate the “enable PING option” so that I can keep track of my trunk status which would otherwise be “unknown”.

I made all my SIP Profile changes on the ShoreTel Trunk side.   This is the  list of configuration options we applied and it was the result of trying and retrying, so this list alone should be worth the blog read as it most definitely works in our example:


If you have never configured a ShoreTel SIP Profile, the video walks you though this in detail.  ShoreTel provides a “standard tie-line” sip profile and suggests that you use it.  In fact if you change it, they generate a strong message urging you not to do so, but change it we did to the settings above and we had a more than acceptable result.

Extension conflict resolution

ShoreTel trunks do not out of the box allow abbreviated dialing.  The Standard ShoreTel domestic dial plan really wants what amounts to an E164 format.   ShoreTel will take all digits dialed and attempt to construct a +1 NPA – NXX – XXXX dial string.   So in this example, we are not going to be able to dial 51 as an access code on the ShoreTel side, then output only four digits.  Not going to work.    As outlined above, ShoreTel will want you to define the OPX extension reachable by the encapsulating trunk group in a detailed list as part.   The good news is that this means that you only have to dial the distant extension number and ShoreTel will see it as an OPX and route it over the associated trunk.

Clearly this means these extensions are unique.   What are we going to do? We have extensions on both sides of the TIE Line that are not unique, they are the same 41xx.   ShoreTel will allow you to create translation table to over come this limitation.   We could create a range of 61xx for our OPX list and then convert it to 41xx in the translation table and that would eliminate our problem.  Not my favorite solution but it may be the one we have to go with.   The down side is that we have no eliminated the 61xx range for use on the ShoreTel side.   Additionally, it is not very friendly to directory systems as people have to remember that if you are calling 4304 in France from New York, you need to dial 6304 not 4304 another colleague in NY!

Ideally we want to make use of that access code.  It would be nice to dial 51 + XXXX and be done with it, but as previously explained ShoreTel does not easily support that option.   It may be possible to write a custom dial plan and apply it to this specific trunk group.   For example, when working with paging adapters that have zones, you want to dial the paging amplifier and then dial your zone.   The custom dial plan for this would by “;1I” but you would still have to dial an OPX number.   For example, you would create the trunk group and maybe put 1234 as the OPX which would route the caller to the paging adapter.  The custom dial plan rule would be interpreted by ShoreTel as “do not echo any digits” enabling the paging adapter to play a second dial tone, and then you could touch tone out some digits.   Sounds like this would be a good solution but you would end up dialing eight digits, but it would free up a range of extensions that might otherwise be eaten alive by the required translation table.

ShoreTel Update

At the end of the day, the solution was to create a custom dial rule and apply it to the ShoreTel Trunk Group.  Users inside the ShoreTel would dial 50+xxxx but as a result of the custom dial rule, the ShoreTel would see 999-555-xxxx and only pass the xxxx.   Remember that ShoreTel wants you to list the extension numbers on the other side of the TIE line in the OPX list of the Trunk Group.  In a situation in which you have extension conflict you can use a translation table, but often that is not the most friendly solution.  Ideally you will want to dial and access code, get connected to the distant phone system and then out dial the extension digits regardless of extension conflict.   To do this on a ShoreTel system will require a custom dial plan modification to the trunk group.  The document on this subject is very limited so you either have to pay ShoreTel  Professional Services or be prepared to play detective.  We went the detective route, so hit us up for the solution.








An IP Blue soft-phone tool kit for serious CISCO voice engineers!

The trials of a Call Center Engineer!

As a consulting engineers, we spend a lot of time working remotely over a VPN connection!  Testing configurations, features and CSS access requires end points!  Typically more than one end point device!   Scripting for the call center applications is even more demanding as you need to be able to test call flows.  Now a VPN over CISCO Anyconnect that allows you to work long hours remote is always nice, is not the same as a point to point VPN.  You might get one IP Communicator up on your local machine, but it is often not practical to register multiple devices.  When testing a UCCX scripts you need multiple Agent and Supervisor Phones to really ring out (pun intended) your call flow.  How best to do this?

Enter IP Blue!

I was taking a CISCO certification class and noticed that the instructor somehow managed to get multiple IP communicators up on his desktop.  I immediately realized the value this would have for UCCX scripting in particular and CISCO CUCM work in general.  I did a bit of research and found a company named IP BLUE Software Solutions, the industry’s best kept secret!  They make some really innovative products, but the one that I now can not live without is the “VTGO-PC Multilab Softphone” a product without equal and one that is a must have for every serious CISCO VoIP Engineer.   With this product I can open some 5-8 7960 type CISCO phones on my desktop, all registered to call manager with individual extension numbers and separate sound interfaces (i.e. speakerphones).   I used to have one IP Communicator and one X-lite SIP phone open on my desk and that was the best I was able to do remotely.  Now I can open an entire call center on my desk!  Astonishing!


Softphone Feature Set

These softphones are fully featured CISCO 79XX models ranging from the 7960 through the 7975 and are completely configurable.   When working with multiple clients I can setup a phone for each system I remote into!  I can even right client on the Instance name and change it to a client name for future reference and quick setup when working on multiple simultaneous deployments! When working on a Call Center I can bring up a few agents, a supervisor and exercise the script for all the possible scenarios.  All on a single desktop!

The feature set includes some really nice, not CISCO features, like an answering machine function!  Very Powerful! Multiple softphone instances can run on a single PC, connecting to the same or different Call Managers.  Each softphone instance is independent from another, and can call any phone including other softphone instances.  This setup allows to easily simulate various call scenarios, verify Call Manager settings, troubleshoot VoIP issues and configure Call Center Scripts results!   If you are running a  lab while preparing for some certification exam, this tool is going to not only save space and electricity, but lower the overall air conditioning requirements!  Here are some of the other features:

  • Emulates Cisco 79xx line of IP phones with dual 14 button expansion modules
  • Tested and certified with CallManagers 3.2-4.1, CallManager Express
  • Supports Cisco Survival Remote Site Telephony, redundant CallManagers, DHCP option 150
  • High quality-low latency using multiple codecs (G.711, GSM 6.10, G.729), QoS support
  • Accessibility features for visually impaired users include text to speech and keyboard shortcuts
  • Supports Extension Mobility
  • XML telephony services
  • Configuration Wizard with user-definable profiles
  • Supports a wide range of external USB audio devices
  • STUN/UPnP NAT traversal, SKINNY fix-up protocol friendly
  • Call log with Callback
  • Call recording, storage and playback with email attachment
  • Integration with LDAP directories, MS Outlook, Windows Address Book, Instant Messengers (Microsoft, Yahoo, AOL)
  • Language Localization (English, Dutch, Danish)
  • Dialing from MS Outlook, Web pages and much more

This is the best kept secret in the industry and if you are a serious student or working engineer doing anything with the CISCO Collaboration suite, you need to own this software.  If you boss will not spend less than hourly rate he bills you out at, get it yourself!  The time you implementation and troubleshooting time you will save, will more than pay for itself in increase leisure and family time!    We rarely pitch products on this site, but this product was just so astonishing we had to share it with our readers!



CUBE SIP Header Matching – Extracting DNIS from a Toll Free Number!

The Problem – Call Forwarding DNIS to Toll Free Numbers

Recently we were presented with a new challenge while deploying a Call Center based on the CISCO UCCX Version 11.5 feature set. Generally, we employ DNIS as a strategy for defining the CSQ  service parameters.   The more specific you can make the inbound number, the less you will need to “prompt and collect” digits from your caller.   A call to a specific DNIS number can separate the English callers from the other language options, or route “customer service” differently than routing “technical support”.   DNIS is always a preferred routing strategy.    Using DNIS we can design a single call routing script that can  pull in the CSQ name; offer up the proper audio menu’s; provide unique queue handling options and customize the caller experience all based on the dialed number.

In this centralized scheduling application for a large national medical practice, patients would call a local number in their community.   This number was then forwarded by the carrier to a toll free number that rang into the centralized CISCO cluster and UCCX call center.   The issue was setting up the dial peers to address the number the caller dialed, not the toll free number.   These numbers terminated on a SIP trunk that was serviced by a CISCO CUBE and the number presented was the 10 digits of the toll free number.   The DNIS number, or the number that the caller originally dialed may or may not be buried in the TO field of the incoming SIP headers.

Solution – Step 1 Debug Captures of inbound SIP messages

We need to setup “debug ccsip messages” and “debug voice ccapi inout” and make some test calls.   We need to understand how the carrier is handling the forwarded number.    In the log output below we can see the INVITE is the 877 toll free number.   The number that the caller dialed is the 9323646969 number and we can see that it is in the TO filed of the sip message headers.   We will need to write a dial-peer,voice class uri,  translation rule and profile that extracts the TO field and routes on that number rather than the original INVITE.   It is the “voice class uri” that is most magical in this solution.   (Note that we got luck here and the carrier was handling the call forwarded number in a manner that was appropriate to our goals.   This however is not always the case)!


Solution Step 2 “Voice Class URI”

In this example, the caller is dialing 93236453XX which is being call forwarded to the  toll free 877 number and shows up in the sip headers in the TO field.   The solution here is to create a “voice class uri”  rule.  In the snippet below we can see “voice class uri 102 sip” with a “user-id of 9323645323” as an example.   We are going to ultimately want to translate this to a four digit extension number 5323 and this is done with the traditional translation rules.  In this example “voice translation rule 102” does this conversion.  Note however that the translation rule refers to a match on the 877 toll free number, not the  9323645323 number.  This is where the magic of  “voice class uri”, the ability to do dial-peer matching based on the uri.

The Voice Class uri is structured such that it has a unique TAG and then a matching expression or host IP address.   The the snippet below we can see two attemtps to setup up a uri filter based on the last digits in the TO field of the SIP header.  Tag 102 looks to match 5323 and tag 103 looks to match 5324:

Solution Step 3 Dial Peer Matching

The call flow is dictated by dial-peer matching.   From the following snippet:

dial-peer voice 103 voip
translation-profile incoming 5324
session protocol sipv2
incoming uri to 103
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0
dtmf-relay rtp-nte
no vad


dial-peer voice 102 voip
description Incoming – FAX DID
translation-profile incoming 5323
session protocol sipv2
incoming uri to 102
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0
dtmf-relay rtp-nte
no vad

We can see that the voice class reference is applied to the dial-peer much the way a voice translation-profile is applied with the expression “incoming uri to 102” which sets up a filter to match for the number  9323645323.  Note that the dial peer matches the voice class but it is the translation-profile incoming 5223 that changes the ten digit number of the URI to the desired four digit extension.  In fact if you study the voice-translation rule 102 rule 1, references the toll free number!

These tools, the voice-translation rule and the voice-class uri work together to enable us to route and match dial-peers on information in the uri and not necessarily the original INVITE sip: number! Way powerful!



Configuring Compliance Recording with CISCO Workforce Optimzaiton

For compliance will you Record Audio or Screen?

There are a range of products and services that can be used to “record” phone calls on a CISCO CUCM, UCCX and UCCE. These products range in sophistication from services that simply save a wav file of a recording which you can search for by time and date, to very sophisticated recorders with advanced index and search capabilities. Some products even include speech recognition functions that can be used to search files for a particular call or even handle a recording base on the audio content.  CISCO Workforce Optimization and Advanced Quality Management adds desktop screen recording and metrics that can also be used for evaluations and service observing.

All of these products have one characteristic in common; they require you to configure a recording capability in your CUCM to copy the media stream from the target source to the recording server. There are a number of options for doing this including SPAN recording and other options that require you to configure your Ethernet switches to accommodate the recording function.  The simplest method to copy media streams is to use the Built in Bridge or BiB of a CISCO phone.  Clearly this can only work for a specific set of CISCO phones, but most phones support this function.

General Recipe!

The following is a basic general recipe for setting up your CISCO CUCM for recording and identifies some of the decisions you have to make along the way.

  • Gateway or Phone;
  • Notification or not; Notify the caller, or the Agent or both?
  • Route Pattern for Recorder along with a Partition and Calling Search Space.
  • Create a Recording Profile;
  • SIP Trunk Setup between CUCM and Recording server; and options CUCM and Gateway;
  • Identify Users and add them to the proper CTI Recording and Monitoring Group;
  • Enable BiB on the phone;
  • Enable Recording on the DN;  Auto always or Selective and reference Recording Profile;

Basically you are creating a conference call between the “source media”, the CUCM and the Recording server.    The actual configuration has a lot of details and you will need to carefully consider each element, but the actual setup is routine for your average deployment engineer.   We summarized them below in video format.

You can also use CISCO XML services to enable SELECTIVE recording in which a phone is recorded only on the demand of the user.  This uses the Calabrio XML api and Phone Service option in CISCO.  This will enable the user to push RECORD, PAUSE, RESUME and STOP.  The second video walks you through the configuration options for that service.  This can also be deployed in Finesse as a desktop button!

Compare CISCO and ShoreTel “dial plans” and “calling priviledges”!

What is a route or dial plan?

Most if not all phone systems provide for route plans and calling or “class of service” privileges.   The dial plan defines the over all numbering system used through out the system.  For example, how many digits do we need to define all of our extension number or telephone endpoints?  What access code do we use to indicate we want an outside line?  What numbers will we set aside for system features like the automated attendant, voice mail, contact center and conference servers?   Generally this is one of the first decisions you make when designing a new phone system.   Once set, it is usually very cumbersome to alter or refine.

Calling privileges or “class of service” defines what facilities a specific user might have access to.   For example, we might want the Lobby and Kitchen phones to be able to dial 911 and make internal calls, but we might restrict them from dialing outside numbers at all, let alone long distance or international phone calls.   Some systems even restrict internal extensions from calling other internal extension numbers.  For example you might isolate the CEO from being dialed by the automated attendant “dial by name” directory and you certainly do not want the over head paging system accessible by an outside caller!

How do we include a new branch with the same internal Extension numbers?

These options become increasingly more complex as organizations redefine themselves as a result of a merger or acquisition.   How do you add that new branch office into the company phone system?  Things become even more exciting when the new office has a “dial plan” that uses the same internal extension numbers already in use by the HQ phone system.   ShoreTel and CISCO tackle this in very different ways and it is interesting to note the different strategies.

In ShoreTel you define you “dial plan” as the necessary first step in designing the phone system.  How many digits do we need to dial internal telephone numbers?  Out of the box, ShoreTel assumes you want to use three digit extension numbers.   You can change them to four, five or more digits but you can only do this once.  You can increase extension digit length but you can not reduce them, so plan carefully!  The next issue is what range will we use for extension numbers?  Will they start with 1, 2 or some other digit?  Don’t forget those “system extensions” as you will need them for many features and system resources.

ShoreTel also uses the concept of a User Group and a Class of Service.   A user group might be a function like Executive,  Manager, Employee and House phones.   The Class of service defines Telephone Features, Calling privileges and Mailbox options.   Telephone features might include who can access the Intercom, or record their own phone calls.   Calling privileges enable internal, local and long distance dialing options.  Finally mail box options indicate the size of messages, greetings and administrative controls.

ShoreTel has a very simple to implement and understand concept for dialing plans and calling privileges.  With simplicity, however, comes some restrictions.   Lets take the example of acquiring a new business unit and they have an existing dial plan that conflicts with the one already in place.   Well, you could through the inplace  phone system out and install ShoreTel at that location (certainly the ShoreTel re-sellers plan) by expanding the existing ShoreTel but that would certainly mean an change in extension numbers at the newly acquired business unit.  Optionally, you could install another ShoreTel system and integrate the two separate system through a SIP  tie-trunk.  Using a digit translation strategy you could let the other guys keep there old extension numbers but you would have two separate telephone systems, each with their own configuration database.   (In CISCO parlance that would be a two “cluster” solution).

ShoreTel Simple or CISCO Complex?

CISCO uses the concept of “route patterns” to define a dial plan.   It is a bit more complex, but with that complexity comes great flexibility.   A “route pattern” is a map for taking the digits a user dials and searching a database to find the route those digits should follow to complete the call.  For example, a user in the California Office might dial 9,1-212-523-51234 to reach extension 234 in the New York office.  The route pattern would then hit route list that might include a local PRI for a long distance call to NY, dropping the 9 and out dialing the E164 1+area code and number.  That route list might also include a WAN gateway that directly terminates in NY and in that case, drops all the digits but the 234 while placing the call over the company’s WAN connection.

To be fair, ShoreTel can also complete a call over the WAN and would be smart enough to know that #234 also has a DID number of 212-523-51234.  If the California user dialed #234, and the call could not be routed over the WAN, the call would be completed over the Long distance line using “PSTN fail over”.  The feature does not, however work the other way.  Had the user dialed the LD number and encountered  a network busy condition, it could not then route the call over the WAN.

As to”class of service”, CISCO uses the concept of a “partition” and a “calling search space” (i.e. CSS).   Though some folks like the “lock and key” metaphor,  we think the best way to understand this is to realize that “partitions” define who can call me.   “Calling Search Spaces” define who I can call.    So if my line or phone is in a CSS that specifies partitions NYPhones, SFPhones, UKPhones, Windstream, COX and Verizon, then those are the objects I can call.    If my device is in a partition named SFPhones and your CSS does not contain that Partition, then you can not call me.

Sounds a bit confusing, and at times it is.   The structure however enables us to build some very  significant solutions.  Take that example in which you have phones with the same extension number in two different business units in the same “cluster” or phone system.   You could put Extension 1234 in the NYPhones partition and in the SFPhones partition!   They would not conflict with each other!  Every phone, feature (i.e. intercom, conference), line in a CISCO deployment is in a specific “partition” and only reachable by an entity that has a Calling Search Space that includes that partition.  Simple!

Given that we are not in the business of selling phone system, only engineering and supporting them, We do not  have an emotional attachment to one over the other.  We observe that ShoreTel is best suited for smaller deployments and in fact can be easily deployed and managed by a small business of 25 or more.   Though there are larger ShoreTel deployments, we see them in the 100 – 1000 user line size most frequently.  CISCO has a low end Solutions, the Business Edition 6K-S for system under 150 users,  but the CISCO Collaboration solution could run a small a small country though the Business Edition 6K and 7K are optimized for 100 – 5000 users!

The video shows the two different approaches to solving these common route plan issues!







HA server in “Split Brain” mode?

What is a High Availability Server Configuration?

HA availability server configuration often results from the sharing of a database between two servers.  One server is Primary or Active, and the other server is Secondary or Inactive.   Generally in the case of Voice Mail servers or Contact Center servers, there is a shared trunk group that interconnects the iPBX or Call Manager to the Active Server.   Should that server fail, the call searches through the trunk group ultimately connecting with the Secondary Server which has now taken on the Primary or Active Roll.   In the case of the Contact Center both ShoreTel and CISCO use this strategy with great results.

Is it “alive”?

A condition known as “Split Brain” can result, however, causing both servers to get “confused”.    This is generally the result of one of three conditions: a server loses power or becomes disconnected from the network during a database replication between the servers; or one of the servers actually restarts during the database replication process.    When this happens database updates to each server may not be replicated to the other server and we get a Split Brain.

The first step in remediation to to recognize the condition!   It  may not be readily identifiable.  In the case of CISCO you can log into the server through the CLI and run utils service database status which will show the present condition of both servers.  If you see the status “connection status unknown” or “Primary/Unknown” or “Secondary/Unknown” you are now in a schizophrenic mode!  Both servers are up and operational but neither server is processing calls as neither server knows that it is the Primary server!  Bad things are happening!


If this condition exists action is required to restore sanity as quickly as possible!

Split Brain surgery!

The remediation can be summarized as restoring each server to a role, Primary/Active and Secondary/Inactive.  Once that is established you will need to pick which database is most current,  and then copy it to the other server, restoring synchronization.  Again CISCO has tools to assist with this process and if followed, this surgery can go smoothly and quickly!  Basically log into the CLI of the server that has the data you want to keep and run the command utils service database status . Then log into the other server and run the command utils service database drbd discard-node which should restore database replication to normal.   Then run the command utils service database status and you should see something that looks like this:


You might then need to double check Distributed Replication Block Device or DRBD meta data for corruption if the servers do not sync up.  This DRBD is what synchronizes data between the two servers.  Check the status as described above and if you see the DRBD error, then run the command utils service database drbd force-keep-node which will reset the DRBD and set the server to Secondary/Inactive.

Ah life in the world of HA!








Upgrading CISCO with Prime Collaboration Provisioning

Don’t Procrastinate!

Sooner or later you will find you need to upgrade your VoIP deployment, regardless of the vendor.   Differing upgrades is just prolonging the inevitable and increasing the complexity and the pain level.   Let’s take the example of migrating a CISCO MCS based cluster that includes a CUCM at version 7.1.5, a UCCX at Version 8.0.2, and a Unity Voice Mail at version 5.0, and some of the components have HA options!  Having put off upgrades for some time, this client will have to migrate from MCS server hardware to vmware ESXi virtual machines and upgrade to the now current 10.X release across the cluster and applications.  In the case of Unity which has been replaced by Unity Connection, this is a completely new application addition.  The complexity of this upgrade is about as challenging as they come!   Additionally, the client expectations are that impact to the production environment will be non-existent!

Build out a “Mirror Lab” system

The decision was made to build out a completely separate “lab” system and to use the same ip topology as the production system.  This in itself is an interesting set of configurations as you will still need to maintain connectivity with all network services, particularly DNS and NTP.   This might best be accomplished with a set of temporary service providers on a completely isolated network.  In this instance we made use of Prime Collaboration Deployment  (PCD) tool to migrate and upgrade the CUCM cluster consisting of Publisher and two Subscribers.   As the “lab” network was to mirror the production network, we actually had three of four subnets to configure as the HA servers were to be located at a different site than the Publishers.   The PCD was relatively painless and very useful.  We did learn quite a lot about the capabilities of this tool, and in the end, consider it to be of great value and we will continue to use it in future migrations.   See our previous blog about lessons learned!

Plan 3 hours per server per Upgrade Step up!

Understanding the time required to complete this process should be established.  The actual time to do a backup and/or a restore of a specific server will be determined in large part by the size of your deployment.   A backup for a single cluster with 100 users will take considerably less time than a backup of a multiple cluster deployment with a 1000 users!   For planning purposes we used one hour per server for installation of software including ISO, COP files and any required Engineering releases.  Each backup added an hour as did each restore.   Keep in mind that you may be making multiple upgrades to achieve your end goal.  Each upgrade will take place in the “inactive” partition. Then you will be required to switch partitions. This process will take as long as a backup to progress!   In this example we were moving from 7.1.5 to 10.6 and that would normally be a multiple step upgrade.  In the case of the UCCX it most certainly was!  So we have, in this example three CUCM servers, 2 UCCX servers, and 2 Unity servers for a total of 7 servers.  At the base level that is a minimum of 21 hours of server operations for each upgrade step!  Plan accordingly and set expectations to all stakeholders!  There will be long periods of watching computer screens and the progress bars that hopefully give you some feel of where you are the process. CISCO upgrades list the number of tasks and also estimate the time per task.  This is very helpful!


Take time to learn COBRAS!

Once we had the CUCM cluster established, we turned our attention to the migration from Unity 5.0 to Unity Connection.  This was achieved by building out a new ESXi based Unity Connection Version 10.5.  CISCO has a great tool to assist with this migration in the form of COBRAS which, if you have not used before, will take some study.  Fortunately there are many training videos on the CiscoUnityTools.com website, where you will go to download the required software.  You will need the CISCO Unity Export tool and the Unity Connection Import tool.   The Export tool needs to be installed on the Unity Server as it will build connectors to the existing Unity configuration and User database.   The tools are not difficult to learn, but do require some orientation.   You can export the configuration including users, call handlers, mail boxes, prompts and even messages.  If you set customer expectations that they will not have historical messages, you can eliminate importing messages which will simplify the process.

The Unity Connector Import tool can be installed on a Windows laptop.  You will need to download and install IBM Informix drivers to connect to Unity Connection Server using a Microsoft OBDC connector.  In this example, we moved from a system that had many less features to a system that had many more features.  Our expectation was that this would be the most painful part of the migration journey, but it turned out to be comparatively easy.   The Unity Connection Server came up with most of the old call handlers matching definitions for new call handlers, and the user database imported with out error.  We choose not to import old messages and set an expectation with the client that there was a point in time in which they would need to clear out old messages as they would not be on the new system.

List and have available all COP files!

Now the upgrade and migration of the UCCX was in fact the most challenging part of the journey.   With the Call Manager now on Version 10.5 the current UCCX 8.0.2 system could not communicate with the call manager.  At first this was not thought to be an issue.  We backed up the UCCX 8.0.2  server and built out the same version machine on ESXi.   Then we did a restore and now had a virtualized UCCX 8.0.2.   You will not be able to log in to the UCCX administration page, however, as the user database is on the CUCM, and the two systems are currently incompatible.  There is a very long list of steps to get to UCCX 10.6 and each step required a backup and restore!  The clock is ticking!

We upgraded the 8.0.2 software to 9.0.2 and found that we need a license key to be able to log into the Administration portal.   Given that we were only temporarily stopping here, and ultimately would license under Prime License Manager, we did not plan for this.  However, we wanted to make sure that all data was successfully migrated to the new version.  So we obtained a demo license through TAC to take a look at our repositories and verify that all scripts, prompts and documents etc. were successfully migrated.   We noted that the Call Control Groups were not in place, but determined that was a result of a  Jtapi version incompatibility.   We next need to apply COP files and migrate to 9.0.2SUS2 in preparation for the journey onward.   At this point, we found a error in the database replication of UCCX servers and elected to remove the secondary server, which we would add back in at a later step.  This required TAC assistance to log in as root and run a script to strip the database of any reference to the second UCCX server.

There are hardware reconfigurations that change as you move through to 10.6 so be aware of them.  As you might have done on MCS upgrades to 9.0.2, you will add RAM and maybe disk drives depending on the size of your UCCX.    So moving from the ESXi virtual 8.0.2 clone we attempted to build out the ESXi machines using Version 10.6 OVA files, but ended up having to download and use an OVA for version 9.0.2.   The upgrade to 10.6 required yet another COP file before the upgrade could be started. Again, it is important to study the various upgrade paths as you may be moving through several upgrades, patches and COP files, so keep track and write it down!  After the COP file, yet another backup!   Finally, we were able to move to 10.6! Once on 10.6 we now needed to add the HA server back into the mix.   Actually, in the future for any multiple upgrade steps it may be best to remove the HA server before starting the upgrade.   Generally this is not a CISCO supported method, but you can see how much time it cuts out of the project as you do not have to upgrade two servers, backup and restore two servers at each step of the process!

Now that we have a complete system upgraded and virtualized, we can do some testing. Specifically working with firmware and CTL issues if any!   Though we did not have any gateways to connect with the outside world, we were able to bring up phones, assign users and make phone calls to the UCCX and the Unity Connection.   What remains is scheduling the maintenance window to facilitate the “go live”.   The plan was to take the old system offline and put the new system online.  Keep in mind we used the same machine names and IP topology in the “lab” as we did in the production environment!




Hosted PBX? CISCO Voice in a Router? (BE6K-S)

The economics of a “hosted” or “cloud” based data and voice service is generally based on moving costs between the hosted provider and your office. The most dramatic example is the cost of the Internet connection. There is an inverse relationship between bandwidth and the equipment location. The more voice and data services that are hosted or cloud based, the more bandwidth you will need to interconnect them to your office. Regardless of which model you go with, however, there are requirements for your “must have” premise equipment that will not change. For example, if your VoIP system is “hosted” in the “cloud”, or if it is located at your office premise, you will still need the very same list of computer network equipment. The equipment requirements for a Firewall, Router, Network Access and Control System, Power over Ethernet switches and phones will exist regardless of where the applications are hosted.

CISCO seems to continually push the marginal cost of adding phone service to that equipment list lower and lower each year. The CISCO Unified Communications Manager, including a fully featured Unity Connection voice messaging and VoIP Paging system with Jabber and presence can now be installed within your network router! If you have an office with less than 150 users and 300 devices, the marginal cost of adding CISCO Unified Collaboration features is basically the software license for the ISR-2900 series router that you will need to purchase anyway! Remember, with the hosted solution you still need to purchase phones and PoE switches to power those phones! Your local area network requires a router to interconnect it with the Internet to reach your service provider. Why not get a router that can act as your firewall, offer advanced intrusion detection and threat protection, and also provide a full range of Unified Communications features?


The BE6K is essentially the same Unified Communications Management and Collaboration solution that is provided in a family of CISCO Collaboration solutions built around the CUCM that ranges upwards of 30K end points! It provides advance phone system features, voice mail, and includes the Prime Collaboration Deployment tool to enable ongoing adds, moves and changes after your system is installed. Jabber enables you to stretch your office extension to anywhere you can carry your smartphone or Ipad! Optionally features include Teleconferencing and Unified Contact Center Express functionality. So what is there to think about?

For the technically oriented business manager, the Unified Communications functionality is running on a VMware ESXi engine installed inside the CISCO router. The normal CISCO router functions are augmented with a single slot blade server, the CISCO UCS E160D, 6 core, 2Ghz 16 GIG Ram processor that supports ESXi. Take a look at this screen shot!


Think of the possibilities! Only a true geek could get this excited but really, VMware running inside a router!

VPN’s and VoIP – Getting economical “full mesh” Connectivity without MPLS!

We see a lot of VoIP deployments that come to us for trouble shooting.  A common problem statement is that our HQ site can call both Chicago and Dallas, but Dallas and Chicago can’t call each other.  Savvy network administrator will have figured out that there is a routing issue, but how so?  Clearly HQ knows how to reach each remote site and the remote sites know how to reach HQ, so where is the break down!   At about this time, we learn they have VPN’s that provide tunnel connections to each location and we go clear!

The standard “tunnel” solutions include IP Security (IPSec), GRE, Easy VPN and the new “tunneless” Group Encrypted Transport VPN or  GET-VPN. Most folks make the mistake of picking IPSec for connectivity and being an inherently point-to-point technology, they end up with the problem statement summarized above.   Even a “hub and spoke” solution is not ideal unless we make it possible for “spoke to spoke” connectivity.   Ideally, we need to configure our VPN so Dallas can communicate with Chicago, without passing through HQ!

IPsec is really an encryption and authentication technology that enable secure communications through a public internet.  It is generally used in a multiple vendor deployments.   IPsec does not support any protocol other than IP,  so it can not be used with the routing protocols that might otherwise be used to solve our issue.   For this reason, many deployments will use GRE over IPsec.   GRE to address the routing protocol issues and the  IPsec to provide the security of authentication and encryption.  We are still however, in a point to point mode, or in heavy manual administration mode to configure a simple mesh!

The smart money is on “next hop resolution protocol or NHRP” used in strategies like FlexVPN, GETVPN or DMVPN.  These solutions provide a full mesh option while providing for encryption and data integrity.   In the problem statement above, had we installed FlexVPN, the Chicago and Dallas sites could communicate directly without having to route through HQ or hub.   We would have “spoke to spoke”  to communications!  As broadband becomes more widely accepted and bandwidth becomes less of an issue, we should see more VPN technology deployed in place or in concert with private network technologies like MPLS (GetVPN over MPLS is really kool).

Give us a call and we can noodle out what “full mesh” technology makes the most sense for your organization, both technically and economically!  We are here to help make the network!