Some of the people I work with have been a real pain in the butt about the music on hold that is on our Call Manager, I asked a Cisco rep if they had any recommended devices to use for the Music on Hold server and the answer that I received was, “CallManager ships with a music-on-hold CD, which contains licensed music. Do you have that CD?” So, as far as I have been able to tell, there are no real solutions that you can just plug into the Call Manager, and the reps who say they have something either can’t seem to call us back or figure out if it will work or not. So, I decided to install a sound card and if I could something to work myself. This is what the FAQ says about the sound card, not sure when this was last updated:
What sound cards can be used with the Music On Hold server?
A. The media convergence servers (MCSs) do not ship with sound cards. If you choose to use a sound card, you need to purchase it separately. The Sound Blaster protocol control information (PCI) 16 sound card has been tested and is recommended for use with the Cisco MCS 7835 and MCS 7835-1000. The Cisco MCS7825-800 requires a PCI 2.2 card. Therefore, no recommended or supported sound card exists for this server model.
So, I tried a couple Sound Blaster sound cards and what do you know, both work and now I can play anything I want through the MOH server. Both of our MCS’ are 7835′s.
I have had a Sound Blaster Live! sb0200 and sb0410 both working in a Cisco Call Manager 4.2 running on an MCS 7835, and currently I have a laptop plugged into the line in port on the sound card and am just playing all of the wav files from the Cisco MOH CD. We will see if the “powers that be” like it or not, as they have not liked anything that I have tried so far, and it would be a lot easier on me if they could give me an idea of what they wanted it to play.
I know a laptop is overkill, but it will work until they decide on something. I know this is going to be a duh huh moment for some of you, but it hadn’t even occurred to me until it happened to me. I had been trying to get them to work while using a remote desktop connection, and while it showed me that the sound card was installed and working properly, under the Sounds and Multimedia Properties icon in control panel, it would say No Playback Device, No Recording Devices, etc. I discovered by accident that it was working perfectly when I replaced the sound card with another and was configuring it locally. Changing the options on the remote desktop connection did not change anything either. Not sure why the configuration wouldn’t look the same, but, I am sure it’s probably some kind of feature.
Another caveat, the people who set up the Call Manager setup both the publisher and the subscriber as MOH servers, the server I originally installed the sound card in was the second one listed under the MOH servers. I remembered reading that the first server was the default, or some similar wording, so I moved the sound card to the first server on the list and it started working. Some things you have to learn the hard way I guess.
Cisco announced this week that their Cisco Unified CallManager and Cisco Unified Presence Servers are vulnerable to remote attacks by using specially crafted ICMP and UDP packets. Cisco has already released patches for them, here.
CallManager servers, which process VoIP calls on a network, can be crashed by sending attack traffic to TCP ports 2000 or 2443 to the server; these ports are used by Cisco’s proprietary call control protocols ? Skinny Call Control Protocol (SCCP, or “Skinny”) and Secure SCCP. This vulnerability exists in CallManager versions 3.x, 4.x and 5.0 (CUCM 6.0, the latest version (announced this month), is not affected, nor is the Presence Server).
Cisco says CallManager and the Presence Server are affected by attacks involving floods of ICMP Echo Requests (pings), or specially crafted UDP packets. The ping-flood vulnerability, which affects only CallManager 5.0 and Presence Server 1.x, could be used to crash call-processing or presence services on the respective servers.
The UDP vulnerability affects the IPSec Manager Service on CallManager and Presence Server, which uses UDP Port 8500. With this less severe vulnerability, an attack could not stop calls from being placed or received on a Cisco VoIP network, but could cause the loss of some features, such as the ability to forward calls or deploy configuration changes to clusters of CallManager and Presence Servers. Source: Cisco VoIP and presence servers vulnerable to new attacks
If you don’t want to load the patches yet, you can block these things at your router on the outside connections to your networks.
Permit TCP Port 2000 (SCCP) and TCP Port 2443 (Secure SCCP) to CallManager systems only from VoIP endpoints.
ICMP Echo Requests, Type 8, should be blocked for CallManager and Presence Server systems (although this could affect network management applications and troubleshooting).
UDP Port 8500 for IPSec Manager should be permitted only between CallManager/Presence Server systems configured in a cluster deployment.
The Register says,
CallManager versions 3.3, 4.1, 4.2 and 5.0, as well as Presence Server version 1.0, are affected by a number of security bugs. The vulnerabilities involve unspecified errors in the handling of large amounts of ICMP Echo packets and within IPSec Manager service, both of which might be used to launch denial of service attacks against vulnerable Cisco Unified CallManager and Presence Server software installations.
A separate bug means that CallManager software PBX systems might be taken down by port scanning. Source: Cisco wraps up against VoIP DoS bugs
Here are some great CallManager Tips from a word document I found on Cisco’s site, here, I have posted some of the ones I needed here, hit the Word doc for the rest.
Time Synchronization – Time synchronization is simply making sure that all the participating CallManager servers and network devices have the same exact time.
All the CallManager servers can be time-synched using the Network Time Protocol (NTP). When you synchronize the time on all involved servers, all the trace files are time stamped the same. When trace files are collected for analysis, you can follow the true series of call processing events with accuracy.
In addition to CallManager servers, you should ensure all network devices such as switches, routers, and voice gateways are synchronized to the same time source as the CallManager servers. This ensures consistent timestamps regardless of which device you are looking at.
IP Phone Tips
IP Phone Won’t Register – Skinny client registration problems are usually caused by a misconfiguration on CallManager, the DHCP server, one or more network devices, or the IP phone itself. Follow these steps when you encounter an IP phone that doesn?t register properly with CallManager:
Step 1 Check for inline power issues.
Step 2 Check IP addressing and DHCP.
Step 3 Check for IP network connectivity.
Step 4 Check for Trivial File Transfer Protocol (TFTP) problems.
Step 5 Check for CallManager issues.
If you have checked for inline power issues and verified that the IP Phone has the correct information, but it still doesn?t register, you need to do some additional investigating. Here are some common reasons why registration fails at this point:
The CallManager service is not running.
The IP Phone can?t reach CallManager. Try to ping the IP Phone from the CallManager server it is trying to register. This will confirm bi-directional IP connectivity.
If NAT, firewalls, or access lists are in use, be sure to check there as well to make sure that traffic is not being blocked, thus preventing proper communication. Skinny devices use TCP port 2000 to register with CallManager.
If the IP Phone must resolve the CallManager name to register, a failure could occur if the DNS server is inaccessible or the DNS entry is incorrect. Generally it is a good idea not to rely on DNS at all. To use IP addresses instead of DNS names, configure the servers in the cluster by IP address in CallManager Administration (System > Server).
The IP Phone firmware load specified by CallManager is not in the TFTP path. If the IP Phone load currently running on the phone is not compatible with the CallManager the phone is trying to register to, the registration might fail. Ensure that the IP Phone is running the firmware version specified in CallManager Administration (System > Device Defaults).
If the IP Phone has never been entered into the CallManager database via CallManager Administration, CallManager does not allow that phone to register unless auto-registration is enabled. Auto-registration does not work unless it has available directory numbers to provide the registering IP Phone a DN. If the IP phone is not configured in CallManager Administration and auto-registration is not enabled or CallManager has run out of DNs, the phone displays ?Registration Rejected.?
Voice Quality Tips
Working with Low-Speed Links – Jitter is more likely to occur on low-speed links because even a single packet in the queue on a low-speed link can dramatically affect the amount of time a voice packet needs to wait in the queue before being transmitted. Jitter can be an even bigger problem if you do not have priority queuing (that is, Low Latency Queuing [LLQ]) enabled on your WAN connections or if you have it misconfigured. It is essential that voice traffic get absolute priority over any data traffic. For more information on using LLQ to prioritize voice samples over data, refer to the Cisco IP Telephony QoS Design Guide, available on Cisco.com (search for ?Cisco IP Telephony QoS Design Guide?) or at the following link: here.
If you are seeing high amounts of jitter over a low-speed link, it?s quite likely that improperly configured LFI is the problem. This is assuming that you are not oversubscribing the WAN link with more voice traffic than what you are prioritizing with your QoS policy. For more information on how to configure LFI, refer to the Cisco IP Telephony QoS Design Guide.
One common cause of drops in an Ethernet environment is a duplex mismatch. Check all the switch ports through which a given call must travel, and ensure that there are no alignment or frame check sequence (FCS) errors. Alignment and FCS errors are usually a sign of a duplex mismatch?that is, when one side of a connection is set to full duplex and the other is at half duplex. To check for duplex mismatches, look at each link between the two endpoints experiencing packet loss and check to make sure the speed and duplex settings match on either side. For more information about troubleshooting duplex mismatches, refer to the Cisco document ?Configuring and Troubleshooting Ethernet 10/100/1000Mb Half/Full Duplex Auto-Negotiation? at the following URL: www.cisco.com/warp/public/473/3.html
Troubleshooting Problems with One-Way or No-Way Audio
One-way audio and no audio at all (no-way audio) are problems that are fairly common during a new IP telephony network installation. The majority of these problems are caused by misconfigurations. For one-way audio problems, always pay attention to which direction the one-way audio is occurring. For no audio in either direction, the troubleshooting methodology is the same. You might need to repeat the procedure for each direction of audio, but more likely you will find the source of the problem when trying to troubleshoot one direction. There are various steps you can take to troubleshoot a one-way/no-way audio problem:
Verify bidirectional IP connectivity
If using an H.323 gateway, make sure you have voice rtp send-recv configured
Check for NAT or firewall restrictions
No Ringback on an IP Phone When Calling the PSTN
One common problem is lack of ringback tone when dialing out to the PSTN from an IP phone. The problem in this scenario is that CallManager automatically cuts through audio to the H.323 gateway as soon as the logical channel signaling is complete. The problem arises because the alerting message sent by the PSTN does not contain a progress indicator indicating that in-band information is available. Typically in an end-to-end ISDN environment, the end device is responsible for locally generating ringback upon receiving an alerting message. Unfortunately, CallManager does not operate this way. It relies on inband ringback when calling out an H.323 gateway. To fix this problem, configure progress_ind alert enable 8 under the POTS dial peer that gets matched for this call?s outbound call leg. For some reason, this command is hidden in some versions of Cisco IOS software, but if you enter it, the gateway accepts it, and it shows up in your configuration.
As soon as this is configured, Cisco IOS Software treats an alerting message as if it came in with a progress indicator of 8. A progress indicator of 8 means that in-band information is available, so the gateway cuts through audio upon receiving an alerting message. There are several other progress indicator values (detailed in Chapter 6 of Troubleshooting Cisco IP Telephony).
No Ringback on a PSTN Phone When Calling an IP Phone
When a Cisco IOS gateway receives a setup message without a progress indicator, it does not play ringback toward the PSTN. This is because the gateway assumes that the PSTN is end-to-end ISDN and therefore handles playing ringback to the originating device upon receiving the alerting message. If the network is not end-to-end ISDN, the setup message should arrive with a progress indicator of 3, indicating that the origination address is non-ISDN. In the case of a failure, the device on the PSTN does not send a progress indicator.
To resolve this problem, you need to configure the gateway to play ringback toward the PSTN regardless of the progress indicator in the setup message. To accomplish this, configure progress_ind setup enable 3 on the VoIP dial peer that is being matched for this inbound call. Note that even though you are trying to fix a problem with ringback on the POTS side, this parameter must be configured on the VoIP dial peer. If you have multiple VoIP dial peers that might be matched, be sure to put the command under all of them.
No Ringback When Transferring a Call
Another common ringback problem is the lack of ringback toward the PSTN user when an IP phone user transfers a call to another phone. The reason for this is a limitation of the H.323 protocol as it is implemented on the gateways and in Cisco IOS.
To get around this limitation, a solution is in place as of Cisco IOS Software Release 12.2(3) and later. This solution also requires CallManager 3.0(8) or later. To get it to work, make sure you are running the correct version of Cisco IOS Software, and make sure the ToSendH225UserInfoMsg service parameter is set to True. In CallManager 3.2(3) and later, this service parameter accepts a numeric value of 0, 1, or 2 instead of True or False.
These values mean the following:
0?Do not send any progress tone information.
1?Use the H225UserInfo message to send progress tone information.
2?Use the H225Info message to send progress tone information.
CallManager versions prior to 3.2(3) do not understand receiving these messages in the H225Info message, so for backward compatibility with CallManager clusters prior to 3.2(3), use a value of 1 (True). Otherwise, choose a value of 2. As long as you have met these conditions, you should get ringback on transfer.
Media Resource Tips
One common reason for both conferencing and transcoding problems is a lack of DSP resources to perform the required function. This could occur either because you have run out of conference bridge or transcoder resources or because the device that requires the resource does not have any available in the MRGL it has been configured with.
Failures to allocate a media resource can be seen in CCM traces and are also logged in PerfMon and RTMT by the OutOfResources counters for Music on Hold, Transcoder, and Conference Bridge in the Cisco CallManager performance object.
If you use Skype very much, then have we got a website for you, VOIP News has listed 25 tips to make your Skype experience better, and hopefully easier as well. after you get done, your Skype will be able to podcast, translate French, take conference calls from 15 people, and tutor calculus, among other things!
Hacking Skype: 25 Tips to Improve your Skype Experience
How versatile is your Skype? Ours can podcast, translate French, take conference calls from 15 people, and tutor calculus. Want to learn how to turn your Skype telephone into a multipurpose office machine? We’re going to tell you how.
For millions of users, Skype is the VoIP solution of choice. If you’re just getting into this great telephone alternative, you are going to be surprised how much you can do with it. In this article we cover 25 tips, hacks, and extras to help you utilize Skype to its fullest potential.
Starting Simple: Built-In Skype Features you Didn’t Know About
Skype is such a rapidly emerging technology that a lot of brand new users aren’t even aware of all the built-in features that Skype offers standard, not to mention the add-ons and hacks that you can improve it with. In this section we cover some often overlooked standard features of Skype that can dramatically improve your experience. Source: Hacking Skype: 25 Tips to Improve Your Skype Experience
Definitely worth the read, even if most of them require you to download a free program to use the feature.
Vonage the Broadband Phone Company is so confident that you will like their VOIP broadband phone service, that they are now offering everyone one month of free service. When you switch to Vonage Internet phone service, you could pay a lot less to get more from your home phone. Just choose the plan that?s right for you. Sign up for the Premium Unlimited plan and get unlimited local and long distance calling for only $24.99/month. Or, sign up for their Basic 500 plan at only $14.99 a month. Either way, you?re making a smart decision. They also offer great international rates, exceptional sound quality, and a bunch of included features: Voicemail, Caller ID, Call Forwarding, and more! And you can even choose your area code or keep your phone number wherever you go. It is win win for everybody. Signup now with Vonage and get One Month Free!
Steve Ballmer, Executive Officer for Microsoft, announced Monday that their latest software will have VOIP and video conferencing, and will enter the market the first of next year.
Executive Officer Steve Ballmer said Monday that the company’s new software will enable voiceover IP and video conferencing functionality.
“We will enter the voiceover IP market at the beginning of next year,” Ballmer said at a Microsoft conference in Tokyo, adding that the software giant will also enter the video conferencing market early next year. Source: MarketWatch
Microsoft and Google can affect markets the same way, but in different ways. When Google enters a market, they might be able to dominate it with a free offering, might, since not all of their pet projects go well. When Microsoft enters a market, you can count on them gaining a big share, if they don’t dominate it outright, and making big money.
What does this mean? Well likely in January Microsoft will begin to show off some consumer VoIP products in a big way at CES, either under cover in private briefings or in their booth. It also means a flurry of activity with so called partners who will all become “Microsoft Certified.” Source: VOIP Watch
Good read at VOIP Watch, describes Microsoft’s strategy when entering a market, and how they are far from inexperienced and probably already have their roadmap all laid out for Live Communications Server.
Here are some great Voive over IP resources from SearchVoIp.com, including News on networking, mobility and voice, breaking news, expert advice and exclusive analysis about the VoIP and IP telephony industries and Telecommunications New White Papers.
Categories: VoIP Tags: