Blog: VoIP

I have been doing some testing on a Lync phone system specifically with response groups and call queues to try to figure out the most appropriate way to design our incoming call routing once we completely migrate to the Lync phone system. The response group features provide most of the features that you need to create basic call center-ish call routing, queuing, and end-user call route feedback. You can configure your response groups to pick up an incoming call and then play a recorded message. You can then configure the response group to provide callers with routing options (like press or say 1 for sales….press or say 2 for support…stuff like that).

My goal was to imitate the current phone system setup as much as possible. Right now, when someone calls the main number (during business hours), it just rings back to the caller until one of the call operators answers. One of the operators must be “online” to receive the call. In Lync, the equivalent of this functionality is to have a response group configured to receive the inbound call and then ring all users who are “logged in” to the response group. The desire was expressed to make sure SOMEONE (not something) be the first to answer the phone. So, from the Lync configuration side, this is basically a response group with no recorded greeting and no user call routing options….the incoming call rings, Lync answers and places the call in the response group for someone to pick up.

The problem is that when Lync picks up the call and transfers it to the response group, it terminates the ring-back to the caller and since the call was transferred to the response group, it starts playing music on hold.....(it’s nice music on hold but could be very confusing to the caller). I struggled with how to fix this and still have the caller have the impression that they were not “talking to a machine”. The solution is somewhat lame, but what the ears hear, the mind believes. Basically, I called into our current phone system, put my phone on speaker and recorded the ring-back with my cell phone. Then, I created a .wav file of the ring-back and set that .wav file as a looping auto greeting for the response group. So, when an incoming call comes into the response group, the caller gets the impression that the phone is still ringing…just waiting for someone to answer. Problem solved.


 
 

We have had recently had a problem with a Cisco 3560 PoE switch and a Toshiba IP phone. The issue is that when a call is made from a Toshiba IP phone (problem spanned phone and phone/firmware versions), the conversion was one way. The party on the remote end could not hear the party in private banking. We have this switch deployed several other places with the same version of IOS and don’t see the issue. Finally the mystery has been solved. After running capture on the links and doing troubleshooting, I was able to determine that the "switchport voice vlan 1" command on each interface that was used for a phone was the magic bullet. For some reason, in its given setup, this switch needs this command to make everything work whereas it isn’t needed in other places. Cisco is current still looking into the issue and last I heard it is at TAC level 4.


 

We recently started having trouble with our voicemail system failing after we rebooted our Cisco Unity server.  It turned out that every time we would reboot the Unity server, the Microsoft Message Queuing Service would hang on startup causing the voicemail to fail.  While on the phone with Cisco technical support, We were informed that if the MSMQ folder (located on Unity at C:\WINNT\System32\msmq) gets larger than 1.5 GB, then the service will never start. [more]We looked at it, and sure enough, it was 1.56 GB. After some trial and error of removing the files in the folder, trying to start the service, failing, and putting the files back in, he finally informed us that we would probably have to reinstall the service.

We reinstalled the Microsoft Message Queuing Service, and the voicemail system started right up. Since then, we have not any high CPU usage problems, no extreme lagging in the voicemail system (that I know about), and hardly any delays in the administration website.