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 (daisy chaining by
using the PC port), the phones will not work.
|
Poor quality when calling digital 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 digital 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’s network
connection and plug the cable into a desktop computer.
Caution
|
The network card in the computer 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 there is no
longer a phone 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 affect their network
connectivity. You must unlock the network configuration options before you can
configure them. For details, see
Unlock and Lock Options.
|
Codec mismatch between the phone and another device
|
The RxType and the TxType statistics show the codec
that is being 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 a transcoder
is in place to handle the service.
For information about displaying these statistics,
see
Call Statistics Screen.
|
Sound sample mismatch between the phone and another
device
|
The RxSize and the TxSize statistics show the size
of the voice packets that are being used in a conversation between this
Cisco Unified IP Phone and the other device. The values of these statistics
should match.
For information about displaying these statistics,
see
Call Statistics Screen.
|
Gaps in voice calls
|
Check the AvgJtr and the MaxJtr statistics. A large
variance between these statistics may indicate a problem with jitter on the
network or periodic high rates of network activity.
For information about displaying these statistics,
see
Call Statistics Screen.
|
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 or the power supply is disconnected
In this case, the switch port on the phone can
become disabled and the following message appears 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 defaults 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 that
are sent to the phone log.
|
|
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 using the 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.
|