Daisy-chaining IP phones
|
Cisco does not support connecting an IP phone to
another IP phone through the PC port. Each IP phone should directly connect to
a switch port. If phones are connected together in a line (by using the PC
port), the phones do not work.
|
Poor quality when calling mobile phones using the
G.729 protocol
|
In Cisco Unified Communications Manager, you can
configure the network to use the G.729 protocol (the default is G.711). When
using G.729, calls between an IP phone and a mobile phone will have poor voice
quality. Use G.729 only when absolutely necessary.
|
Prolonged broadcast storms cause IP phones to reset,
or be unable to make or answer a call
|
A prolonged Layer 2 broadcast storm (lasting several
minutes) on the voice VLAN may cause IP phones to reset, lose an active call,
or be unable to initiate or answer a call. Phones may not come up until a
broadcast storm ends.
|
Moving a network connection from the phone to a
workstation
|
If you are powering your phone through the network
connection, you must be careful if you decide to unplug the phone network
connection and plug the cable into a desktop computer.
Caution
|
The computer network card cannot receive power through the
network connection; if power comes through the connection, the network card can
be destroyed. To protect a network card, wait 10 seconds or longer after
unplugging the cable from the phone before plugging it into a computer. This
delay gives the switch enough time to recognize that no phone
is on the line and to stop providing power to the cable.
|
|
Changing the telephone configuration
|
By default, the network configuration options are
locked to prevent users from making changes that could impact their network
connectivity. You must unlock the network configuration options before you can
configure them. See
Unlock and Lock Options
for details.
|
Codec mismatch between the phone and another device
|
The RxType and the TxType statistics show the codec
that is used for a conversation between this Cisco Unified IP Phone and
the other device. The values of these statistics should match. If they do not,
verify that the other device can handle the codec conversation or that a
transcoder is in place to handle the service.
See
Call Statistics Screen for information
about displaying these statistics.
|
Sound sample mismatch between the phone and another
device
|
The RxSize and the TxSize statistics show the size
of the voice packets that are used in a conversation between this
Cisco Unified IP phone and the other device. The values of these statistics
should match.
See
Call Statistics Screen for information
about displaying these statistics.
|
Gaps in voice calls
|
Check the AvgJtr and the MaxJtr statistics. A large
variance between these statistics might indicate a problem with jitter on the
network or periodic high rates of network activity.
See
Call Statistics Screen for information
about displaying these statistics.
|
Loopback condition
|
A loopback condition can occur when the following
conditions are met:
- The SW Port
Configuration option in the Network Configuration menu on the phone is set to
10 Half(10-BaseT/half duplex).
- The phone receives
power from an external power supply.
- The phone is
powered down (the power supply is disconnected).
In this case, the switch port on the phone can
become disabled and the following message will appear in the switch console
log:
HALF_DUX_COLLISION_EXCEED_THRESHOLD
To resolve this problem, re-enable the port from the
switch.
|
Peer to peer image distribution fails.
|
If the peer to peer image distribution fails, the
phone will default to using the TFTP server to download firmware. Access the
log messages stored on the remote logging machine to help debug the peer to
peer image distribution feature.
Note
|
These log messages are different than the log messages sent
to the phone log.
|
|
Cisco VT Advantage/ Unified Video Advantage (CVTA)
|
If you are having problems getting CVTA to work,
make sure that the PC Port is enabled, and that CDP is enabled on the PC port.
|
Phone call cannot be established
|
The phone does not have a DHCP IP address, is unable
to register to Cisco Unified Communications Manager, and shows a Configuring IP
or Registering message.
Verify the following:
-
The Ethernet cable is attached.
-
The Cisco CallManager service is running on the Cisco
Unified Communications Manager server.
-
Both phones are registered to the same Cisco Unified
Communications Manager.
-
Audio server debug and capture logs are enabled for both
phones. If needed, enable Java debug.
|
Call established with the iLBC protocol does not
show that the iLBC codec is being used
|
Call statistics display does not show iLBC as the
receiver/sender codec.
-
Check the following by using Cisco Unified Communications
Manager Administration:
-
Both phones are in the iLBC device pool.
-
The iLBC device pool is configured with the iLBC
region.
-
The iLBC region is configured with the iLBC codec.
-
Capture a sniffer trace between the phone and Cisco
Unified Communications Manager and verify that SCCP messages,
OpenReceiveChannel, and StationMediaTransmit messages have media payload type
value equal to 86. If so, the problem is with the phone; otherwise, the problem
is with the Cisco Unified Communications Manager configuration.
-
Enable audio server debug and capture logs from both
phones. If needed, enable Java debug.
|