Archive for the ‘Troubleshooting’ Category

SIP and MGCP – Friends or Foes

Informational, Troubleshooting | Posted by admin
Jun 25 2009

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

Scrambled UC500 Brains

Troubleshooting | Posted by admin
Apr 13 2009

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.