Well this one certainly caused me some heartache. I’m posting it here in hopes that it helps someone else.
I don’t remember when exactly it started or why, but I noticed that when I tried to shut down my virtual machines, they would lock up. I could not tell what was wrong with them and if I tried to use VM -> Power -> Off they would get to 95% and then lock up.
I would end up having to reboot the VMWare server to get them back online.
While doing some VM upgrading, this was happening a lot. It got frustrating enough for me to start seriously trying to figure out the problem.
Reviewing the VMWare server logs showed a lot of “Sync CR” messages in the log. These indicate reservation conflicts for SCSI control in VMWare.
It seemed that for some reason, my problem was not VMWare, but the iSCSI initiator on Openfiler.
For me this issue was resolved by restarting the iSCSI initiator service like this:
/etc/init.d/open-iscsi restart
This should be a last resort though, since, without properly shutting down your VMs, it WILL seriously anger the VMWare server and probably screw up any virtual machines running on the iSCSI drive.
Here’s the scenario: We have a Cisco Unified Communications Manager 6.1, an MGCP controlled VG224, a SIP trunk to the PSTN and hardware transcoders. We place the SIP trunk and VG224 into different regions so that they should use the g.729 codec. Transcoders go into a region that will always use g.711.
Symptom : Calls show up on the SIP gateway as g.711, not g.729
This is because the system is using transcoders to complete the call. The big question is ‘Why?’. Both devices are natively capable of supporting g.729, but they insist on using a transcoder. The transcoder sits in a g.711 only reason, so both sides of the gateway run g.711.
Here’s the reason why : When calls connect to a SIP trunk in Cisco’s Communications Manager, the system will dynamically allocate a Media Termination Point (MTP) if the two endpoints are configured with incompatible DTMF signalling types. Since transcoders can be used as MTPs, a transcoding session is invoked.
In many cases VG224s are used to handle Fax calls. For those who don’t know… Fax machines and transcoders don’t mix. But even if there are no fax machines in the mix, at remote locations this issue can cause overutilization of bandwidth.
The solution is simple, just make sure that all of your endpoints use compatible DTMF relay methods.
For example in MGCP
mgcp dtmf-relay voip codec all mode nte-ca
is compatible with this command in SIP (RFC-2833)
dtmf-relay rtp-nte
I had the opportunity recently to troubleshoot some erratic and intermittent UC500 problems. The issues were everything from dropped calls to echo on some calls.
It seemed that two phones were actually bad and had to be replaced. But the real fun came when I checked out the log:
 070782: Apr 9 xx:xx:xx.xxx: %IP-3-LOOPPAK: Looping packet detected and dropped -
src=192.168.1.101, dst=192.168.1.1, hl=20, tl=229, prot=17, sport=138, dport=138
in=Vlan1, nexthop=192.168.1.1, out=Vlan1
options=none -Process= “IP Input”, ipl= 0, pid= 75, -Traceback= 0×80E38860 0×8131DCDC 0×8131F3C4 0×81560EC4 0×815611E8 0×81562A64 0×81306F24 0×8130ADD0 0×8130BC04 0×8130BCF4 0×8130BEB8 0×801778EC 0×8017A1EC
These entries were filling up the log fairly quickly. The first thing I noticed was that all the packets had the same port numbers: netbios. At this point I checked the interface configurations and found a configuration like this:
interface Vlan 1
ip address 192.168.1.1
ip helper-address 192.168.1.1
I can’t think of any good reason the helper-address would be pointed to itself, so I removed it. This resolved all the issues the customer was having outside of broken phones.Â
Simple fix, but very interesting impact on system functionality.