UCCX and UCCE with Voice and Video

Video Call and Video Chat for Cisco UCCX/UCCE

Video in contact center is something we’re hearing more and more about lately. Video call and video chat will most likely become conventional contact center channels thanks to WebRTC and zealous marketing from major UC&CC vendors.

Let’s not put here marketing stuff about how cool it is. Instead, we’ll consider ways to enable video in Cisco UCCX/UCCE.

The first thing that comes in mind is Cisco Jabber Guest – a native solution from Cisco that helps web-visitors interact with enterprise workers, including contact center agents. Users click the URL link and their browser open an audio/video session to wherever Jabber Guest Server routes them. On the back-end you’ll need the Cisco UCM, Cisco Jabber Guest server with Cisco Expressway-C/-E and internal video-enabled endpoint.

As guests, your website visitors are offered:

• a point-to-point audio/video,
• in-call control through a keypad,
• the ability to mute video, audio, or both.

While this could be enough to offer a guest access to your employees (for associates, suppliers, partners etc), the use of Jabber Guest in the contact center is a big question because of two major issues:

1. Jabber Guest requires a browser plug-in to be installed before making a call. A client will hardly agree to spend his time installing the plug-in to make a single call to your contact center. He heeds a “click-to-video” feature, but not the “click-to-install-to-video” one.
2. When calling through Jabber Guest a client has no collaboration features. The dual video definitely improves the communications  – you see the person you’re talking to and how he reacts to what you’re saying. But to provide the real LIVE assistance your agents need to collaborate with clients like they’re in person – exchange the docs, co-work on the website, show, point, discuss etc.

So, when thinking about video call / video chat channel for your contact center you should also consider third party solutions designed specifically for the customer service. The key features that make them different from Jabber Guest are:

• no downloads or plug-ins are required even for mobile browsers (thanks to WebRTC),
• integration with contact center software,
• web-collaboration features – chat, app sharing, co-browsing,
• interaction recording.

There are several vendors of video chat solutions on the market, of which Aurus RichCall is the only that claims to be designed specifically for Cisco UCCX/UCCE:

• it inherits UCCX/UCCE agent accounts, skill groups and routing rules,
• the video call bypasses the IVR menu and gets routed right to the appropriate skill group,
• the agent’s UI is integrated with Cisco Finesse or Cisco Agent Desktop (CAD),
• each video chat session is  reflected in Cisco Unified CCX Historical Reports and Cisco Unified Intelligence Center,
• the audio is recorded by the call recording software already deployed in contact center.

Seems to be quite a niche solution, but developed by Cisco Solution Partner for Cisco contact center platforms. So, if you’re running the UCCX/UCCE-based contact center, it may be of your interest.

Customer service done correctly

I spent some time today thinking.  I have been told by numerous sources how I am good in front of customers.  They tend to like me, request that I do things, and overall I improve the relationship between people.  Now I'm sure I'm not the only one doing this in my current company, but I wanted to share some things as an engineer that I think are what contributes to my success so far.  I know this isn't voice related but it is professional related to any field out there.  The more you use the foundation of being a human being and professional the better the results.  Remember, integrity, ethics, courteousness, and knowledge!

-----------------------------------------------------------------------------------------------------------------------------

Customer Service Done Correctly

Over the last twelve years I have experienced much and if it is one thing I have learned, the more humanly you treat people, the better the results.  This thought process didn't radiate at first with me.  When I was in my adult teens and early to twenties I felt like I had something to prove.  I think that might be a stage that everyone goes through; I just went through it quicker.  If it's one thing the military does, it is get you into a mature state of mind earlier.  Having seen the world and the plights of different cultures, one thing has remained a constant, treating people like human beings.  You would be surprised at how well people with completely different beliefs or thought processes can get along.

Since my exit from the military due to medical issues, I have gained insight as to how to handle customers, even when they are upset.  The mindset I keep can turn a relatively rocky start into a blooming relationship in which a customer may request you to perform a service you might not be qualified for.  The reason behind the request is that they are both comfortable with you and know your ethics and standards.  Every professional in any field should have a high level of both of those areas, ethics for doing the right thing despite the consequences and standards for getting something done correctly and efficiently while maintaining proper records of everything for later.

When it comes to servicing requests from customers, everyone involved should always be one-hundred percent informed.  Even if it was something as simple as a ticket already completed by someone else, someone should know.  When someone knows, someone can act properly in the event something else occurs.  If someone already removed a phone description and replaced it with something else that was requested, record that it was already done, follow up with the customer and move on to the next task.  Every time you inform someone that something is done, the concept of work is being done is felt.  With that feeling, a relationship begins to form.  Continuing on that relationship is entirely up to you and how you handle future encounters.

That brings me to the next idea that has popped off since talking about customer service.  The more detailed and well-presented information, the more likely you are going to give the customer, co-workers, and manager the warm and fuzzy.  Keep things presentable and neat as well as well documented.  If you start annotating times you did things, great, keep at it but remember to only get as detailed as you can within the allotted time.  My way of documenting and reporting may be completely different from the way you do it but as long as it is presented well and detailed everything should flow.  A good example of what not to do when handling documentation is to be vague or brief such as the following:

·         "Fixed the directory number."

·         "Added phone"

·         "Created new dial plan for end user to accommodate request"

The above examples are worthless as anyone can write those sentences.  Again, you need to be detailed and well presented.  Different circumstances will force different documentation.  For instance, putting information in a spreadsheet and sent in an email is fantastic but might not work so well in a service ticket unless you attach the file.  You may need to make a bulleted list of the things you did.  Instead of doing what I showed in the examples above, you should be getting more detailed like such:

·         "Removed directory number xxx-xxxx as it was the wrong DN assigned and in the wrong partition"

·         "Assigned a new DN (xxx-xxxx) to the device and placed it in the correct partition of 'PT-Blah'"

·         "Added one Cisco 7965 with a MAC of AAAA.AAAA.AAAA and a DN of xxx-xxxx"

·         "Called customer to confirm everything is as it should be, (customer name) confirmed that everything is functioning properly, closing ticket"

The above example is everything I would normally put into one ticket if it was pertaining to an IP Phone configuration problem or add/change/remove.  When you get that detailed, people will know what happened, why it happened, and how to fix it in the future if you are not around.  Furthermore, that level of detail shows time, care, and knowledge.  If you took the time to write detailed information, you probably care about the issue and want to make sure that the customer is taken care of.  Additionally, making that final call to the customer for confirmation will make them happy, even in the worst of days.  I had one customer that was absolutely irritated at the world when I was assigned a ticket that involved rebuilding a call server.  I got it all completed, updated them, and showed them screenshots of me fixing everything every step of the way.  I called them to let them know it was fixed and even invited them into a WebEx Meeting (online screen sharing, video, and audio meeting) to show them that everything is the status quo.  The next thing I know, I am going out to that very location to do a review of what was done on an entirely different project not even related to my profession.

When presented with a problem, go out and tackle it head first.  If you mess something up, let the customer know and reassure them that you are taking the proper corrective actions to remedy the situation.  No one ever grows and gets better by staying idle in their small corner that they are comfortable with.  No one is perfect in this world, we all make mistakes.  Some may say that is easy to say but hard to deal with and I disagree.  The more you learn and try, the better you become.  I once deleted a directory number in a server that wiped out 20 phones.  I could have sworn it wasn't me as I wouldn't make a mistake like that.  I went back and checked and ultimately found out I did, despite not remembering.  Either I was really tired that day or slammed with tickets.  I went back into my ticket log, found my actions and referenced that with the audit log of changes and sure enough I screwed up.  I informed the correct people and the issue was resolved.  Don't have fear of screwing up and don't have fear of telling someone the truth, the more you do it, the easier it gets.  This doesn't mean that you should go busting up servers then telling people, just be honest and in return you will learn and be treated well.

All of this leads back to treating people like a human being.  Despite some peoples’ bad behavior or attitudes, you are there to do a job and get it done correctly.  Being courteous, efficient and detailed, people will calm down and start talking.  I do understand that some people won't fit this bill, some are just downright rude, but you still have to try and you still must be courteous, efficient, and detailed.  If someone is being hard to deal with and you still get the job done, they will probably come back assuming everything is understood and aren’t misled or misinformed as to what occurred during the entire job.  Those that are disrespectful, you can simply choose to not do business with them again.  The smile, candor, and professionalism should always be present; you owe it to the customer because they are paying your bills for both yourself and the company that you represent.

Helios Integration with CUCM

     Over the last few days I have been fiddling with a Helios door control system that a customer wanted to implement.  Getting the Helios device itself setup appears to be fairly straight forward but I am in no way an expert on configuring the device side and thus won't offer advice or steps for that portion.  However, the CUCM side of things I can definitely post some useful content for those that are having problems getting their Helios up or just want some information.

Here is a list of things you need to have configured:

1. End-User, preferably with CTI control and CCM End User access as this is how mine is setup
1. Digest Credentials for the end user, not just a PIN/Password!
2. Third-Party SIP Device (Advanced)
3. DN must be set or the SIP device will not register

     So basically, you make an end user, set their password/pin if needed but the digest credentials at the bottom of the first portion of the end user config is most important.  These credentials will be needed by the Helios to register.  The next part is assigning CTI and CCM End User access.  Is this necessary? I don't believe so since other than a PLAR like functionality, the Helios doesn't need anything extra, still, I have seen some with issues and this fixed it for them so I enabled it anyways.

     The next thing you need to do is make a third party SIP device and make sure it is Advanced.  From here, put the MAC in, assign the end user as an owner, and then towards the bottom, make sure you set the digest user accordingly.  Next assign a DN, because as we know, in SIP, if you do not assign a DN it will not register.  While you are at it make sure the line as the proper CSS if needed to dial the number it needs to dial for PLAR style communication.

     Finally, go back to the end user that you made and make the end user control that device.  Once all of this is complete, check back on the device to see if it is registered (assuming the Helios side is already configured correctly).  From here all you should have to do is press a button on the Helios and it should dial straight down to whomever you set. 

Cisco MediaSense Recording

     For those of you that use MediaSense or are considering it.   I've never had the pleasure (or displeasure) of working with the system.  Basically, MediaSense lets you record conversations be placing it in between the IP Phone and the CUCM.  With the call recording, the media gets forked which basically duplicates the RTP audio and sends it to the Cisco MediaSense.  As of today, only the Cisco IP Phone and CUBE can fork the media.  The idea behind the CUBE is that it can record other SIP devices not Cisco related as well as two external calls like a cell phone to another cell phone (Think Mobile Voice Access). 

     Rather than type out an entire blog on the topic, you can go to this link here: http://www.voicecerts.com/2015/03/cisco-uc-call-recording-with-mediasense.html 
for more information and a better overview of what it does.  Additionally, here is the link to the EOS/EOL announcementfor 9.X.  Luckily, 10.X is out there so Cisco MediaSense isn't going anywhere.  I'd also like to point out that I had to amend this article as I had made a boo boo about saying MediaSense was being retired when in fact only 9.X was being put away.  Cisco continues to develop this technology. 

CUCM 9.X DRF/DRS Backup issues

I was doing an upgrade from CUCM 7.x to 9.x last Friday which lead to some headaches that I wanted to post here to help alleviate those issues on anyone else.  Long story short, we ran into to bugs that haulted the backup and restore process.  The first bug involved a 7.x license issue where it would tell us we could not upgrade during a licensing grace period.  This was completely bogus as the CUCM was fully loaded with DLUs and was not over the DLU count.  Cutting to the chase, the TAC engineer had to go in and delete a mylicense file in the root of CUCM.  The other workaround was to apparently use a v1.3 cop file instead of the 1.5 refresh.  The issue here? The 1.3 is nowhere to be found on Cisco's site and TAC wouldn't just give us the file.

The second issue was one where we tried to backup the new 9.x CUCM but only TFTP and two other options were backed up. There was no opportunity to select the CCMDB, MOH, ANN, etc.  At first we thought that since the backup was a 1 GB, which was larger than the 7.X backup, we were good to go.  TFTP generally just backs up the firmware if you were wondering.  Well, it turns out, that since 8.x, a bug occurs where, despite having all services activated and running, the backup options for the rest of the CUCM i.e. ELM, CCMDB, etc., don't appear.  The fix is to go into the control panel and manually deactivate the services then reactivate them.  Note I said deactivate/activate, not start/restart.  You must follow those instructions.  Once I did this, the issue resolved itself and we could pull a solid 9.x DRS.

A simple post about simple things in CUCM

     I figured I needed to make another post today.  It's been awhile and I like to keep things fresh when I have the time.  I have been knee deep in service tickets for a customer lately and have been trying to keep track of those one offs that people rarely encounter, but when they do, can never find an answer.  I figured today I would post some simple things about CUCM if you didn't already know.  For anyone that actually reads my blog, this stuff is very basic so if you are a CCNP Voice or a CCIE then you can probably read on because you are bored.  Nothing to follow will be of use to you if you are already at that level.

CUCM Phone Registration Unknown vs Unregistered:

     This one time and time again has come to me by junior voice initiates.  They find a phone that isn't working and assume that something is terribly wrong because it went unregistered.  The problem is, phones can go unregistered for a myriad of reasons from switch failures, network failures, the phone itself dumping, someone blocking traffic on the network, etc.  The key here is to check RTMT and see why the phone unregistered.  It generally gives you a cause code when you look at the syslogs of CUCM. 

     On the matter of Unregistered and Unknown, keep in mind that Unknown generally indicates that the phone has never been on the network...since the last restart of CUCM if it ever has been restarted.  What this means is that if you never restarted CUCM (assuming this is a fresh install since everyone reboots at some point) and the phone is Unknown you might want to check the phone and make sure it has power, the correct VLAN on the wall drop, and is programmed with the correct MAC address.

     When a phone is Unregistered, this indicates that the phone was on CUCM and registered at some point between before you logged in and since the last reboot.  Something has happened between then and now.  This could be something like a user unplugging the phone, the switchport being shutdown, etc.  Check to see if you can ping the IP address, if the phone still responds to ICMP but is failing to register, I would perform a reboot of the phone followed by a factory reset if that doesn't solve the problem. 

     As you can see, the two status messages of the phones indicate what steps to take in order to solve the problem.  My write-up is by no means an exhaustive list of things you can do.  You could always setup a packet capture with wireshark and see what is going on as well.  Maybe the phone is requesting a file upon boot that for some reason, it is not getting.

Unity Connection Voicemail distribution

Last week I was looking into a solution to fork voicemail to multiple outlook inboxes.  The reason behind this was that a general voicemail inbox for two people needed to go to both of them.  Natively, the voicemail would just sit on the phone itself since it didn't have an account associated.  Thus the problem as you can see. 

I sat around and did some testing.  Accept and Relay worked fine but you can only relay it to one inbox.  The work around here is to send it to a distro list so multiple people can get the voicemail attachment.  This works great if your exchange admin is around or is willing to make a distro list.  With red tape and other obstacles, I wanted a way to do this myself without needing someone else and thus my resolution assuming you are not forwarding something to the same domain.

So below are a few ways to handle this problem.  I will start with the extremely easy and preferable way since you can just make one change and be done.

In the above image, if you select a user/general mailbox and go to edit --> message actions you will come to this screen.  I set voicemail to accept and relay then typed in the relay address I wanted the voicemail to go to.  Keep in mind that your policies needs to permit whatever email address you put in here should it go outside the network.  This method is the easiest and most preferred as you can simply make a distro list and push it to that address and be done in 5 minutes.  This would require your exchange admin to help you since he/she has to make the distro list for you.


This image shows you a screen from Edit --> notification devices.  From here you can go to HTML and send the voicemail to an address or SMTP and send the voicemail to an address.  The only problem here is that it cannot be in the same domain as the Unity connection email domain.  So forwarding to something like gmail would work great here.  If you really wanted, you could then auto-forward that email from gmail back to another user elsewhere within the domain.  Pain in the butt? Yes it is, but it is a work around.

These methods are usable at the very least and can solve a problem if needed.  Honestly, option one is the easiest possible method and should be used.  I can see option 2 usable for users that need external access too if they ain't at their laptop or don't have their corporate email on their phones (who doesn't these days...).  It's a solution I thought worth keeping note of since I didn't know about it until someone on the CSC forums showed me.