Beruflich Dokumente
Kultur Dokumente
03
This troubleshooting guide explains the operation of an IP Phone in a VoIP environment. Its aim is to
help diagnose and resolve problems in activating the IP Phone.
This document concentrates mainly on the latest IP Phone version, called integrated or V2 IP Phone (e-
Reflexe range).
1
2
OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES
CONTENTS
2. HISTORY......................................................................................7
3. REFERENCES................................................................................7
APPENDICES
APPENDIX 1 - STATUS OF THE IP LINK
2. HISTORY
Edition 01: Creation of the troubleshooting guide.
Edition 02: Addition of section 7.14 IP Phone reset with cause "Reset hard requested" / Alarm 378
Cause 6.
3. REFERENCES
4. OPERATING PRINCIPLES
In an Alcatel OmniPCX4400 Enterprise context, an IP Phone should be able to set up IP links to
different entities:
During the initialization phase, links are set up to a DHCP server (Alcatel OmniPCX internal
or external) , and then to the TFTP server.
In normal operation (set idle) a signaling channel is set up to an INTIPA board.
During a call, the signaling transits through the signaling channel set up with the INTIPA
board and the RTP flow transits through an additional channel. This can be set up directly
with another IP Phone (direct RTP) or with an Alcatel OmniPCX IP board if
compression/conversion resources are required for routing the call (INTIPA/INTIPB/TSCLIOE/
GD).
To be able to set up all of these links, at a minimum, an IP Phone must be configured with the
following parameters:
Its own IP address, a sub-network mask, the router address (if a router is present in the
network), and the address of the TFTP server. These parameters can be configured in static
or dynamic mode; the operating mode must be programmed by an operator:
In static mode: an administrator should program these parameters in each set according
to the network addressing plan, this method is adequate for a small configuration.
In dynamic mode: A DHCP server provides the addresses, and the server may be Alcatel
OmniPCX internal or external. A single external DHCP server will allow homogeneous
and coherent management of the IP addressing plan, because it can integrate all the
voice and data network equipment.
The speed, the operating mode of the IP Phone ports and of the switch output must be set by
the operator:
The following combinations are possible:
Speed: 10 or 100 Mbits/s
Half-duplex mode, full duplex mode, or Auto-negotiation mode (the IP Phone
adapts the speed and the transmission mode to the configuration of the equipment with
which it will interconnect: switch, hub, etc.)
The IP Phone is capable of managing the quality of service Level 2: 802.1Q which may be
activated. If the quality of service is activated, the operator should configure the VLAN
number on which the IP set will be connected. In version 2.18 of the IP Phone and R5.1 of
the Alcatel OmniPCX Enterprise, the assignment of the VLAN number can be dynamic using
the "AVA" function (feature not officially released, still under Special Deal Process).
Three files are downloaded when starting up the IP Phone (during TFTP exchange):
lanpbx.cfg (characterizes the Alcatel OmniPCX system and gives the IP addresses of the TFTP
server and of the system CPUs).
bintscip or bintscipS or binipph1 (the binary file of the V1, V1S or V2 IP Phones).
starttscip (initializes the UDP port that the IP Phone should use for exchanges with the
system).
Step 1 The IP Phone sends a DHCP request (message type DHCP DISCOVER) with a request for a
VLAN identity. The request is sent to the VLAN by default. This request is sent without an
802.1q tag.
Step 2 The DHCP server (integrated into the telephone equipment) replies with a DHCP reply
(message type DHCP OFFER) with a VLAN number identifier and a multicast type IP address.
Step 3 The IP Phone switches to 802.1q tag mode with the VLAN number received previously.
Step 4 The IP Phone sends a second DHCP request (message type DHCP DISCOVER) with the
802.1q tag to the VLAN received in step 2.
Step 5 The DHCP server designated to process this request replies with the IP address of the IP
Phone and the address of the next server (call server address).
Step 6 The IP Phone sends TFTP requests to the call server to obtain the following information
(lanpbx.cfg, binaries, starttcsip).
The equipment that is able to handle this VLAN number by DHCP is identifiable by the presence of
an explicit request in the "vendor specific" options. Option 43 will be used in this request. Option 43
(0x2B) is also called "encapsulate vendor options" described in RFC 2132.
The option is constructed as follows:
The VLAN number to be distributed depends on the sub-network on which the DHCP discover packet
is received. If the IP Phone is in the same sub-network as the Call Server, it will give the set a VLAN
ID identical to the one used by the Call Server. If the set is in a different sub-network, the DHCP
server will extract the sub-network number from the information given to it by the relay DHCP, and
will then assign a VLAN ID based on this.
All "ALCATEL" DHCP clients who make the request will receive a VLAN number: the "client vendor
class" option must start with "alcatel.....".
The VLAN number is sent in the "vendor encapsulated option." The same message described
previously is used for this reply.
In step 2, the DHCP server will assign a multicast type IP address to the set. The network manager
must provide this address, and it must be consistent with the sub-network in which the set is located
and meet the current rules for routing in the network. This IP address will not be used by the set; it is
a temporary address, and it is released at the end of the DHCP exchange.
Router IP address
The second DHCP Discover request is sent, the frames are tagged
802.1Q with the VLAN number which has been given by the first
DHCP server in the DHCP Offer message [1]
At the end of the DHCP exchange, the IP Phone systematically makes a "ping" request to the address
of the router indicated to it by the DHCP server in the "DHCP Offer" message and confirmed in the
"DHCP Ack" message.
Phase 1: the IP Phones for which the download requests (RRQ) are the first two to reach the
server will be processed in full; the (N-2) IP Phones which make a download request on the
binary will receive a specific 32013 ABORT code in response (see section 3.5.3), indicating
that they must start up by flashing the binary that they already have (commissioning without
downloading the binary). This procedure allows network traffic to be unblocked quickly.
Phase 2: the server resets the first 21 IP Phones (in the second phase 21 simultaneous
downloads are therefore processed). With each completed download, the server resets a new
IP Phone, which maintains the number of simultaneous downloads at 21 and avoids the two-
minute timeout triggered when all the downloads in progress are completed.
Important reminder
There are three scenarios where the IP Phone download is not carried out immediately after start-up.
These are when:
The download simultaneous requests limit is reached (24 number of INTIPAs declared).
The local sub-network is saturated, and the TFTP server response time is too long; the set
stops downloading and starts up on the version stored in its memory.
More than 100 IP Phones are declared, the system sequences the downloading (maximum of
21 parallel downloads) and asks each set to start up on the version stored in its memory.
Caution: In the scenarios mentioned, the system will force the set to reset so that it has to
update its version. This reset is provoked once availability of resources is guaranteed and at the
latest after the release of a call in progress. An end user may therefore see their set restart without
being able to identify the cause of this reset.
Download time from a CPU5/CPU6 with a configuration with at least 100 IP Phones.
4.1.2.4.1.Lanpbx.cfg file
When the IP Phone starts up, it will try to load the lanpbx.cfg file that contains vital information for
the correct operation of the set.
The lanpbx.cfg file is stored on the hard disk of the Alcatel OmniPCX 4400 in the following directory:
/usr3/mao or /DHS3data/mao
If the file does not exist on the disk, it is created in the memory when the TFTP process is run.
This file must contain the following information:
(1)krk> cd /DHS3data/mao
(1)krk> more lanpbx.cfg
TYPE=A4400 VERSION=1 IP_DOWNLOAD=192.168.65.42 IP_CPU1=192.168.65.40
IP_CPU2=192.168.65.41
IP_DOWNLOAD = IP address of the TFTP server. This IP address is the one from the main CPU of the
node on which the IP Phones are declared (IP address of CPU xm00000). The TFTP server may also
be external to the Alcatel OmniPCX 4400. The IP Phone will download its binary from this TFTP
server.
IP_CPU1 = address of CPU xa00000
IP_CPU2 = address of CPU xb00000
The IP_CPU1 and IP_CPU2 addresses must be given in the case of a duplicated system. The
addresses xa00000 and xb00000 are the so-called physical addresses corresponding to the
Ethernet interface 0 of each CPU. An IP Phone connected to an Alcatel OmniPCX 4400 accepts only
one connection per telnet initiated by one of these two addresses.
The lanpbx.cfg file may be created or modified using the lanpbxbuild command run on an
Alcatel OmniPCX 4400.
The IP Phones must be reset after each modification to the lanpbx.cfg file.
Caution: The IP Phone download will not be possible if the lanpbx.cfg file does not exist or is
incorrect. It will not be possible to access the IP Phone debug mode by telnet.
The binaries for the IP Phones are stored on the hard disk of the Alcatel OmniPCX4400 in the
following directory:
/usr2/downbin/ or /DHS3bin/downbin
The binaries used are:
bintscip for the V1 IP Phone (TSC-IP V1 or IP enabler).
bintscipS for the V1 S IP Phone (TSC-IP V1S or Fast IP enabler).
binipph1 for the integrated or V2 IP Phone (V2 or e-reflexes IP Phone).
The version of the binaries available on the hard disk of the Alcatel OmniPCX4400 can be read as
follows:
(1)krk> pwd
/DHS3bin/downbin
(1)krk> readhead binipph1
16 first bytes >>>
......
ab_binary_name : binipph1
separator : _
version_number : 2.13.00
separator : _
date : 09Dec02_17h34
.....
The IP Phone makes a first attempt to download this file by setting the hsize option (request to
download the file header only). The IP Phone compares its binary version with the one given in the
header of the downloaded file:
If the version is identical, the IP Phone moves on to the next step,
Otherwise, it makes another request to download the complete file to update its own binary. At
the end of the download the set copies the downloaded binary to the flash memory and resets.
Option: hsize
........................................................
Keep-alive sequence
UDP D=32000 S=32640 LEN=9
1 - 0x04
UDP UA MESSAGE - DHS => SET
KEEPALIVE - 0x04
Caution: The previous figures show that an IP Phone in a call must be able to set up two
channels and keep them active:
The signaling channel (set up with the call server through the INTIPA board),
The audio channel (set up with another IP set in RTP direct mode, and an INTIPA or INTIPB
board, depending on the availability of compression resources and the proximity of the
party).
Following routing problems, one-directional calls or calls without sound may be observed if the
audio channel cannot be set up (the address of the router has not been given to the IP Phone or is
incorrect, the router configuration is incomplete, a route is not defined, etc.)
When setting up a call (incoming or outgoing), there is an exchange of UA messages encapsulated
in data packets between the IP Phone and the INTIPA board. The IP Phone exchange to INTIPA is
carried out on the UDP port specified in the starttscip file.
This exchange deals with the sending of keys, updating displays, icons, etc.
Once signaling is set up end-to-end, the system sends the start_rtp command to the IP Phone
(via the INTIPA). In this message, the system gives the IP address of the correspondent as well as the
UDP port open on the recipient.
The IP address of the correspondent may be that of another IP Phone for an IP Phone to IP Phone
call and using RTP direct.
This IP address may also be the address of an INTIP board on which the compressor that will make
the translation to the non-IP world will be seized.
The choice of INTIPA or INTIPB boards can depend on the availability of compressors (load
distribution), on a configuration by domain, or on the proximity of the calling or called set
equipment.
Setting up and cutting off the RTP flow is not synchronized. ICMP destination unreachable (port
unreachable) messages can be observed when the remote port is not yet open (on start_rtp) or
already closed (on stop_rtp). This behavior is normal and does not harm the quality of the audio link
set up.
..
[192.168.65.41] [192.168.65.45] 78 RTP Payload=G.723 audio SEQ=45504 SRC=2911365538
[192.168.65.45] [192.168.65.41] 106 ICMP Destination unreachable (Port unreachable)
..
[192.168.65.41] [192.168.65.45] 78 RTP Payload=G.723 audio SEQ=45513 SSRC=2911365538
[192.168.65.45] [192.168.65.41] 78 RTP Payload=G.723 audio SEQ=25623 SSRC=1093238624
..
UDP UA MESSAGE - DHS => SET
DATA - 0x07
Expected sequence number 13
Sent sequence number 16
UA MESSAGE - DHS => SET - Length 3
ALL ICONS OFF - 0x46
UA MESSAGE - DHS => SET - Length 4
LED COMMAND - 0x21
Command : 0x07 -> All leds off
UA MESSAGE - DHS => SET - Length 4
IP DEVICE ROUTING CODE - 0x13
Command : 0x02 -> Stop RTP
6.2. Help
The help command can be run at any time. It gives the list of commands available in the integrated
IP Phone. The "help" command without a parameter lists all the commands available with all the
possible parameters for each of the commands.
IpPhone > help
help
......
3 defence [nombre] | status | help
....
10 id (list all identity informations)
11 level flux seuil
flux: all
|debug|trace|rtp|jitter|rtcp|ua|ua_msg|dsp|eim|mgr|supervisor|init|display|kbd|aom
seuil: only messages with a level >= seuil are displayed
20 ping help | version | @ip
.....
The redirect command allows all of the all flows to be redirected towards the "eth" interface.
6.7. Defenses
The uptime command shows how long an IP Phone has been operational.
The IP Phone stores the last 100 reset causes for the set. This information can be consulted using the
defence command.
IpPhone > defence 99
defence 99
- ......
-017 000-00:01:15.160 reset hard requested by supervisor
-016 000-00:02:52.820 reset hard requested by TSC protocol
-......
-011 000-00:02:26.910 reset hard requested by TSC protocol
-010 000-00:00:21.530 reset hard dwl step: flashing, status: SUCCESS
-009 005-00:40:42.820 reset hard requested
-008 000-04:20:42.320 reset hard requested
-007 001-19:13:52.990 reset hard requested by TSC protocol
-006 000-00:00:20.590 reset hard dwl step: flashing, status: SUCCESS
-005 002-22:19:17.390 reset hard requested
-004 000-03:11:48.470 reset hard requested
-003 000-00:01:14.800 reset hard requested
-002 000-00:04:56.050 reset hard requested
-001 000-00:19:29.230 reset hard requested
>000 001-14:58:29.250 reset hard requested
defence OK
The last reset cause:
IpPhone > defence
defence
IpPhone > >000 001-14:58:29.250 reset hard requested
defence OK
IpPhone > ua
ua
IpPhone > Receive Transmit
CONNECT = 1 1
CONNECT_ACK= 1 1
RELEASE = 0 0
RELEASE_ACK= 0 0
KEEPALIVE = 4158 ACK= 4158
DATA = 16 9
ACK = 8 13
NACK = 0 0
DATA_bad = 0
NACK_bad = 0
errors = 0 0
bad content= 0
bad len = 0
bad peer = 0
bad state = 0
ua stats OK
For the call in progress, the IP Phone uses G723 compression without VAD ("Voice Activity
Detection"); the transmission framing is equal to the reception framing which is 30 milliseconds.
The IP Phone ("local (192.168.65.91:32002...") communicates with a remote IP equipment device
("remote (192.168.65.93:32040..."). The RTP flow is exchanged on UDP ports 32002 on the local
IP Phone and the UDP port 32040 on the remote IP Phone.
The call duration is indicated in: "duration (000-00:01:06.840)".
During a call, the RTP and DSP statistics can be consulted. The statistics are available in both call
directions. These statistics are accessible using the "voice" command followed by the "n2d" or
"d2n" parameters:
n2d = network to dsp (digital signal processor): IP link to IP Phone direction, or
d2n = dsp to network: IP Phone to IP link direction.
Statistics in the reception direction:
IpPhone > voice n2d
voice n2d
IpPhone > NET_to_DSP
rtp
seqnum 32349
total 40954
update fail 0
dsp lost 13 RTP statistics
rtp lost
voice frame 40954
sid 0
dtmf 0
dsp
total request 40958
total ok 40945
miss empty 0
miss late/lost 13
sid 0
DSP statistics
silence 0
bfi 13
bfi cons max 7
voice OK
6.10. Traces
Different trace levels can be activated in the integrated IP sets. These traces are available "on the fly"
on the Ethernet interface if the data flow has been redirected using the redirect command. The traces
can be activated on a protocol layer, a particular module, or all the points accessible in a trace. The
level command without parameters gives the command syntax.
The IP Phone start-up phase cannot be traced using this method; the traces can only be started up if
the set is connected to the system (at the end of the initialization phase).
IpPhone > level
level
IpPhone > level flux seuil
flux: all
|debug|trace|rtp|jitter|rtcp|ua|ua_msg|dsp|eim|mgr|supervisor|init|display|
kbd|aom
seuil: only messages with a level >= seuil are displayed
level KO
The "flux" parameter (flow) must specify the protocol layer or the module to be traced. "all" activates
the trace on all the points available in a trace.
A trace level may be specified by the "seuil" (threshold) parameter. The usual values are as follows:
Seuil = 0 activates the maximum trace level for the specified "flux"
Seuil = 999 deactivates the trace for the specified "flux."
0 <= seuil <= 99: For more precise investigations, intermediate values can be set by the
development equipment.
The following example activates the trace of the UA layer, the set is idle, the activated trace allows
the "keep-alive" mechanism to be highlighted:
IpPhone > level ua 0
level ua 0
IpPhone > level OK
000-03:44:45.280 ua_udp: received KEEPALIVE
000-03:44:45.280 ua_udp: ua_udp_timer_link_lost_run()
000-03:44:48.380 ua_udp: received KEEPALIVE
000-03:44:48.380 ua_udp: ua_udp_timer_link_lost_run()
000-03:44:51.490 ua_udp: received KEEPALIVE
................
level ua 999
level ua 999
IpPhone > level OK
Run the domstat command to have access to the list of IP equipment on a system. This command
identifies the INTIPA boards that are present which are likely to manage signaling links with IP sets,
their IP addresses and their physical positions in the shelves as well as the distribution per IP domain.
(1)krk>domstat
+--------+--------+-------+-----------------------+-----------------+
| Type | Cr/Cpl | Neqt | Mac Address | Ip Address |
+--------+--------+-------+-----------------------+-----------------+
| INTIPA| 0/ 4 | 10244 | 00:80:9f:04:f7:d3 | 192.168.065.044|
+--------+--------+-------+-----------------------+-----------------+
| INTIPA| 0/18 | 10251 | 00:80:9f:04:fe:59 | 192.168.065.105|
+--------+--------+-------+-----------------------+-----------------+
----------------------IP Terminals in domain 0 DEFAULT_DOM ----------------
+--------+--------------+--------------------+-+-----+---------------+----+
| QMCDU | Name | Mac Address | |Neqt | Ip Address |Type|
+--------+--------------+--------------------+-+-----+---------------+----+
|31050 |31050 |00:80:9f:3d:00:dc:00|V|00470|192.168.065.182|Intg|
|31051 |31051 |00:80:9f:3b:6e:32:00|V|00471|192.168.065.178| V1S|
+--------+--------------+--------------------+-+-----+---------------+----+
The ippstat command identifies the INTIPA board that manages the signaling channel of a given
IP set.
(1)krk>ippstat
The following command allows connection to the INTIPA board and access to the trace commands.
In the following example we want to trace the signaling link from set 192.168.065.182 which is
managed by the INTIPA coupler in position 0 18.
(1)krk> cpl_online 0 18
00000651-1CE6D17E: Connected to Crystal 0 Coupler 18
Escape character is '^D'
We want to activate traces on a "dl" = data link. By selecting choice 4 we activate the trace, so that
only connection messages are traced; choice 5 allows an extended trace to be displayed, so that all
exchanges with the IP Phone are reported.
Caution: The trace only starts up if a new data link is set up! In other words, on starting up an
IP set, the trace is not activated on a link that is already set up. The trace will exist for as long as the
link between the INTIPA and the set exists, regardless of whether the trace is stopped.
Caution: This trace should not be run on sites that implement a large number of IP Phones
(>100 sets).
In all cases, think about stopping the traces at the end of the investigations.
TSCIP:dl
(0) Clear flag
(1) Discard reception : Not implemented
(2) Discard transmission: Not implemented
(3) Loopback (up) : Not implemented
(4) Trace : 0
(5) Extended trace : 0
(6) Debug mode : 0
Your choice ? :4
000005A0-1CE32DA8: End of command execution
TSCIP:dl
Your choice ? :5
000005A1-1CE33406: End of command execution
00 00 01 B8 EC 00 00 00 01 4A E8 00 00 00 41 00
13 0A 03 14 4E 75 6D 62 65 72 20 6E 6F 74 20 61
76 61 69 6C 61 62 6C 65 04 0E 20 33 31 30 35 30
20 2D 20 33 31 30 35 30 05 17 41 34 34 30 30 20
4E 65 74 77 6F 72 6B 20 30 20 4E 6F 64 65 20 31
30 05 00 13 09 03 04 01
000005AB-1CE3700C: FL_0x00:(Wait 0001, Tx 0001) - Rx DATA (Rx 0001, Ack 0001)
000005AC-1CE3700C: DL_0x00:(Wait 0001, Tx 0001) - ack_test : ack_num_seq=1,
last_ack_num_seq=0, sent
_msgs_no_ack=1 -> OK3
000005AD-1CE37017: DL_0x00:(Wait 0002, Tx 0001) - Tx ACK (Last_ack 0001, no_ack
0000)
(0005) 07 00 02 00 01
000005AE-1CE37017: DL_0x00:(Wait 0002, Tx 0001) - Tx DATA
(0008) 07 00 02 00 01 01 00 2A
000005AF-1CE37017: FL_0x00:(Wait 0002, Tx 0002) - Rx DATA (Rx 0002, Ack 0002)
000005B0-1CE37017: DL_0x00:(Wait 0002, Tx 0002) - ack_test : ack_num_seq=2,
last_ack_num_seq=1, sent
_msgs_no_ack=1 -> OK3
000005B1-1CE37022: DL_0x00:(Wait 0003, Tx 0002) - Tx DATA
(003E) 07 00 03 00 02 02 00 06 00 03 00 2C 00 02 0A 00
36 01 08 04 1E 1F 1E 04 08 00 0A 00 36 02 00 1F
1F 1F 1F 1F 00 00 0A 00 36 03 00 08 12 15 0E 04
04 04 0A 00 36 04 02 05 02 00 00 00 00 00
000005B2-1CE37022: DL_0x00:(Wait 0003, Tx 0003) - Rx ACK (Rx 0002, Ack 0003)
000005B3-1CE37022: DL_0x00:(Wait 0003, Tx 0003) - ack_test : ack_num_seq=3,
last_ack_num_seq=2, sent
_msgs_no_ack=1 -> OK3
000005B4-1CE37125: FL_0x00:(Wait 0003, Tx 0003) - Rx DATA (Rx 0003, Ack 0003)
000005B5-1CE37125: DL_0x00:(Wait 0003, Tx 0003) - ack_test : ack_num_seq=3,
last_ack_num_seq=3, sent
_msgs_no_ack=0 -> OK1
000005B6-1CE37130: DL_0x00:(Wait 0004, Tx 0003) - Tx DATA
(000F) 07 00 04 00 03 03 00 2C 00 00 03 00 2C 01 02
000005B7-1CE37130: DL_0x00:(Wait 0004, Tx 0004) - Rx ACK (Rx 0003, Ack 0004)
000005B8-1CE37130: DL_0x00:(Wait 0004, Tx 0004) - ack_test : ack_num_seq=4,
last_ack_num_seq=3, sent
_msgs_no_ack=1 -> OK3
000005B9-1CE37389: DL_0x00:(Wait 0004, Tx 0004) - Tx KEEPALIVE
000005BA-1CE37389: DL_0x00:(Wait 0004, Tx 0004) - Rx KEEPALIVE_ACK
000005BB-1CE375D0: DL_0x00:(Wait 0004, Tx 0004) - Tx DATA
(007F) 07 00 04 00 04 02 00 32 04 0C 00 49 03 1A FF 09
CB 44 80 18 0A 04 3A 06 00 3E 06 FF 97 7F 17 03
00 39 00 08 02 00 04 01 04 00 30 05 05 00 01 00
46 02 00 21 07 01 00 46 02 00 21 07 03 00 21 00
02 04 00 47 0A 00 00 03 00 21 00 00 03 00 21 00
01 03 00 21 00 04 03 00 35 00 00 05 00 31 00 05
23 21 05 00 38 00 0F 00 0F 03 00 21 00 02 0B 00
27 40 04 32 32 2F 30 38 2F 30 33 02 00 13 06
000005BC-1CE375D1: FL_0x00:(Wait 0004, Tx 0005) - Rx DATA (Rx 0004, Ack 0005)
000005BD-1CE375D1: DL_0x00:(Wait 0004, Tx 0005) - ack_test : ack_num_seq=5,
last_ack_num_seq=4, sent
_msgs_no_ack=1 -> OK3
000005BE-1CE375DC: DL_0x00:(Wait 0005, Tx 0005) - Tx ACK (Last_ack 0005, no_ack
0000)
(0005) 07 00 05 00 05
The set initialization is finished, the set is idle, and the trace indicates the "keep-alive" exchanges:
000005BF-1CE3782A: DL_0x00:(Wait 0005, Tx 0005) - Tx KEEPALIVE
000005C0-1CE3782A: DL_0x00:(Wait 0005, Tx 0005) - Rx KEEPALIVE_ACK
000005C1-1CE37A83: DL_0x00:(Wait 0005, Tx 0005) - Tx KEEPALIVE
000005C2-1CE37A83: DL_0x00:(Wait 0005, Tx 0005) - Rx KEEPALIVE_ACK
000005C3-1CE37CDC: DL_0x00:(Wait 0005, Tx 0005) - Tx KEEPALIVE
..................
..................
00000645-1CE41583: DL_0x00:(Wait 0005, Tx 0005) - Tx KEEPALIVE
00000646-1CE41583: DL_0x00:(Wait 0005, Tx 0005) - Rx KEEPALIVE_ACK
When the power supply to the set is cut off, the set no longer replies to the "keep-alive" request:
00000647-1CE417DC: DL_0x00:(Wait 0005, Tx 0005) - Tx KEEPALIVE
00000648-1CE418A5: DL_0x00:(Wait 0005, Tx 0005) - Tx KEEPALIVE
00000649-1CE4196E: DL_0x00:(Wait 0005, Tx 0005) - Tx KEEPALIVE
0000064A-1CE41A37: DL_0x00:(Wait 0005, Tx 0005) - Tx KEEPALIVE
0000064B-1CE41B00: DL_0x00:(Wait 0005, Tx 0005) - Tx KEEPALIVE
0000064C-1CE41BC9: DL_0x00:(Wait 0005, Tx 0005) - Tx KEEPALIVE
0000064D-1CE41C92: DL_0x00:(Wait 0005, Tx 0005) - Tx KEEPALIVE
The link with the IP Phone is considered lost, the information is reported by the INTIPA board, and all
the signaling channel characteristics are reported and stored in the internal trace of the INTIPA
board:
0000064E-1CE41D5B: DL_Ox00: Link state event 0 (reason 6)
7. DIAGNOSTIC HELP
7.2. IP Phone does not start up: incorrect configuration of the DHCP server
Problem
the IP Phone does not start up; it is waiting for the user/operator to enter the set number.
Symptom
In dynamic mode, the IP Phone successfully passes the initialization phase (goes from state 1/6 to
6/6) but remains blocked in the state where the operator must enter the set number and the
secret code.
Analysis and Explanation
This problem appears if a DHCP server points to two TFTP servers (two Alcatel OmniPCX CPUs
from two different nodes). After a network cut-off or a CPU loss on a node, all the IP Phones of
this node access the second TFTP server (which is a CPU from a remote node). Because the sets
are not registered here, a registration request is sent to the IP Phone (request for a set number
and a password).
Solution
Check the configuration of the DHCP server. The DHCP server should point to a single TFTP
server.
If the set is in this state, it must be forced to reset (cut off the power supply). During the initialization
phase (between phase 3/6 and 6/6) which follows, the "debug" mode must be activated by
successively pressing first the [i] - MENU key and then the # key, in order to check the coherence of
the IP configuration: IP address, router address and TFTP server address.
Caution: If the users give the set number and password, the sets will be registered on a remote
node. Serious malfunctions may be observed on the installation if the link between the two nodes is
a link with small bandwidth.
Likewise, router A should be configured so that it knows the route to the INTIPB.
DECT set
Solution
In dynamic addressing: the configuration of the DHCP server should be coherent and give
the address of router A to the IP Phone A.
In static addressing: the operator/administrator should give the address of router A during
the configuration of the IP Phone A.
This point can be investigated by checking the configuration of the IP Phone as follows:
Investigations to be performed
Telnet connection in the IP Phone:
(1)krk> telnet 192.168.65.91
Trying 192.168.65.91...
Connected to 192.168.65.91.
Escape character is '^]'.
A ping to the INTIPB is attempted:
Ping KO!
IpPhone > ping 192.168.65.85
ping 192.168.65.80
IpPhone > 004-07:43:31.390 ping 192.168.65.85 KO
Check the IP Phone configuration, the coherence of the router address must be checked:
IpPhone > config
config
IpPhone > config: current flash
Static : static static
Local addr: 192.168.65.91 192.168.65.91
SubNetMask: 255.255.255.0 255.255.255.0
Router : xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx
Tftp addr : 192.168.65.80 192.168.65.80
Tftp port : 69 69
Main cpu : 192.168.65.80 192.168.65.80
VLAN id : 4095 (0x fff) 4095 (0x fff)
VLAN using: no no
dwl method: full full
PLC g711 : simple (default) simple (default)
Ethernet : LAN:100/Half PC:no link LAN:auto PC:auto
config OK
A ping to the router is attempted:
IpPhone > ping xxx.xxx.xxx.xxx
ping xxx.xxx.xxx.xxx
IpPhone > 004-07:43:31.390 ping xxx.xxx.xxx.xxx KO
Etc.
Or
(1)krk> ippstat
IPP (IP Phone) information :
-------------------------------------
Display the IP Address of the local node : 1
Display IP Phone data of a set : 2
Display all IP Phone on local node : 3
Display registration terminaisons(short info): 4
Display registration terminaisons (long info): 5
7.8. Error codes 4.12 and 4.03 appear during the initialization of the IP set
Problem
The IP Phone presents Error codes 4.12 and 4.03.
Symptom
Despite the fact that error codes 4.12 and 4.03 display on the V2 IP sets during its initialization
phase, the sets still come into service.
Analysis and Explanation
In system version D2.304.4.b, the binaries of the V2 IP Phones are not available during the
binary loading request; the TFTP server returns an error code indicating that the binaries are
absent.
Solution
Update the site with a binary version which supports the V2 IP Phones, or recover the IP Phone
binaries and copy them to: /DHS3bin/downbin
To be able to use the V2 IP Phone binaries, the site must be upgraded to at least version
D2.304.4.s.
Software versions from which the V2 IP Phone is supported
Caution: It is important to have all the corrections that have been made in the latest version of
the IP sets available; the latest version released is V2.18.
Example of trace carried out during investigations:
Reading the compression statistics on the headquarters router: the compression factor is 1.42
Routeur_C7206>sho ip rtp header-compression
RTP/UDP/IP header compression statistics:
Interface Multilink309:
Rcvd: 5588 total, 4412 compressed, 0 errors
0 dropped, 16562 buffer copies, 0 buffer failures
Sent: 447 total, 308 compressed,
6492 bytes saved, 15376 bytes sent
1.42 efficiency improvement factor
Connect: 16 rx slots, 16 tx slots, 236 long searches, 139 misses
68% hit ratio, five minute miss rate 0 misses/sec, 0 max
Reading the compression statistics on the remote site router: the compression factor is 2.70
Routeur_C2610>sho ip rtp header-compression
RTP/UDP/IP header compression statistics:
Interface Multilink1:
Rcvd: 420 total, 285 compressed, 0 errors
0 dropped, 0 buffer copies, 0 buffer failures
Sent: 5929 total, 4328 compressed,
146146 bytes saved, 85772 bytes sent
2.70 efficiency improvement factor
Connect: 16 rx slots, 16 tx slots,
9 long searches, 575 misses 28 collisions, 0 negative cache hits
90% hit ratio, five minute miss rate 0 misses/sec, 0 max
Problematic site topology: degraded voice quality in reception on IP Phones of remote sites.
Caution: In the following configuration, only three (3) simultaneous G729 calls are
possible on the E1 link. The limitation is imposed by the limited performances of the C7206
router (compression rate for the RTP/UDP/IP headers inferior to that of the C2610 router).
UA
CPU
RTC
CISCO C7206
router
CISCO C2610
router
Remote site
IP Phones
Solution
Two solutions exist:
Select 30-millisecond framing.
Update the IP Phone version to the version 2.18.
Correction
The problem is recorded in anomaly report CDHva59959, the correction is available as of versions:
D2.304.4.x - D2.313.7.j - D2.314.4.c.
7.14. IP Phone reset with cause "Reset hard requested" / Alarm 378 - Cause 6
Problem
IP set reset because keep alive mechanism is broken.
Symptom
Data network either does not transmit keep alive mechanism or IP set receives frame that make it
dummy -> does not answer to keep alive mechanism.
Analysis and Explanation
The origin of the problem could be different:
1. A default routing of the packets in the data network keep alive frames not received by IP
Phones - The matter is that the switch (Cisco) periodically recalculates its table of MAC
addresses for answering to ARP requests. If the parameters "switchport block multicast y
switchport block unicast" of the Catalyst 3550 are set, the time for this calculation can be
about 12 seconds, that could provoke the disconnection of many IP Phones. When
disabling these parameters, the mentioned time came down to 3 seconds, low enough to
keep the connection with IP Phones.
2. Frames received by IP set make it dummy no keep alive ACK sent by IP set (see example
of data network trace below). The problem occurs when the IP set receives in the same
clock interruption 2 large frames, so it has no time to manage both frames.
Correction
The second topic is a problem recorded in anomaly report XTSce35528, the correction is
available in the IP Phone 2.21 version.
Note
Dial-in or Telnet access is also desirable to help with effective problem resolution.
The table below shows the real status of the IP link operating mode according to the configuration of
the equipment items connected opposite each other. Invalid configurations are shaded gray.
Caution: The IP Phone may give an incorrect speed or mode indication (half-duplex/full duplex
mode) if an invalid configuration is selected.
ERROR CODES
The errors that may be detected during the initialization phase of a terminal are listed in the
following table.
The error codes are the ones displayed by the integrated IP set (V2 IP Phone).
Note
Num X.Y: X = step; Y= status
Status string: the display of this information may be truncated to adapt to the size of the
screen on the set
F/B: Action F = Fatal (causes set to reset); B = blocking, with or without reaction by the set
E/W: Display W = Warning (for information); E = Error; S = normal step
NETWORK TRACES
In the following examples you will find recommendations for how to carry out traces on the IP link of
the IP Phone. During certain investigations, it will even be necessary to place network monitoring
equipment on the IP Phone side and the home INTIPA board side. This method will allow network
responsibility to be determined in the event of an IP Phone/Alcatel OmniPCX4400 problem.
We recommend the Wireshark (http://www.wireshark.org/) network protocol analyzer utility to do
the traces.
Example 1
switch
OmniPCX
PC with trace tool IP Phone under observation 4400/Enterprise
In the configuration above, the trace is carried out on the port of a switch. The port of the IP Phone
under observation is configured to mirror to the port on which the network monitoring PC is
connected. The advantages of this method are:
It does not modify the configuration of the IP link of the set under observation,
A given context is retained, the set does not reset when the trace is started, and the IP link is not
interrupted at any time.
However, it also has disadvantages:
The information traced on the port configured to mirror is incomplete; the 802.1 tagging of the
frames is not always faithfully sent to the port of the PC being used as the network monitor.
This configuration requests calling the manager of the DATA network to modify the switch
configuration.
Example 2
HUB
switch
OmniPCX
PC with trace tool IP Phone under observation 4400/Enterprise
The IP Phone and the PC are connected behind a HUB. Using a HUB risks modifying the
configuration of the IP links between the IP Phone and the switch, with the HUB ports operating in
half/duplex mode. Particular attention should be paid to the coherence of the IP Phone and switch
port configurations. To avoid Ethernet collisions, the switch and IP Phone ports must be configured in
autonegotiation or forced to half-duplex mode. The coherence of the speed settings for the ports
must be checked and respected.
The advantages of this method are:
All information visible by the IP Phone can be traced, including level 2 802.1Q tagging, etc.
This method can be put in place without the help of the network manager (as long as the
configuration of a switch port does not need to be modified).
The disadvantages of this method are:
Putting the HUB in place will require the interruption of the IP link between the switch and the IP
Phone; it will be necessary to generate a reset of the IP Phone and thus modify an established
context (for example a blocking or etc.).
The configuration of the ports for the equipment involved must/will be modified (so operation
will have to be in half-duplex mode).
ADD-ON MODULE
Caution: The old 20-button and 40-button add-on modules are not compatible with the
integrated V2 IP Phones, as the keys of the add-on modules are not recognized. These old add-on
modules do work very well with V1 and V1S TSCIP sets.
New modules are available which inter-operate perfectly well with V1, V1S TSCIP, and integrated IP
Phone sets.
These modules are available with the following references:
40-key Add-on:
Packaged 40 add-on Reflexes Module: 3AK27107ADAB
40-key add-on Reflexes Module: 3AK26044ABAA
20-key Add-on:
Packaged 20 add-on Reflexes Module: 3AK27107DDAB
2-key add-on Reflexes Module: 3AK26043ABAA
These new modules are easily recognizable: they have "add-on UA/IP" on the packaging and on
the label stuck under the module.
When Alcatel IP Phones from the e-Reflexes family (V2 IP Phone, 802.3af compatible) are powered
via the Ethernet ports of the Cisco Catalyst 3550 PWR switch, they operate and provide the same
advantages as if they were powered conventionally, by their independent power supply.
It is however important to note that it is mandatory to force the bit rate and Duplex mode on the
e-Reflexes Alcatel IP Phones so that the Ethernet ports of the CISCO switch provide the power supply
on the Ethernet link.
=> An e-Reflexe IP Phone for which the Ethernet port is configured in autosense/Autonegotiation will
not be powered via the Ethernet ports of the Cisco switch.
Notes
1 A few tests have been carried out with Alcatel IP Phone from the old family (4098, 4098FRE
modules) with negative results. The majority of the tests carried out were performed using the
latest CISCO Catalyst 3550 PWR software version available: IOS 1.12.1.13.EA1 (version
currently provided on the CISCO WEB).
2 A few tests have also been carried out with the version delivered with the switch (IOS
1.12.1.12C.EA1), but these tests are not considered representative due to the short test period
with this version.
TEST ON THE POWER SUPPLY OF THE ALCATEL IP PHONE BY THE ETHERNET PORTS
OF THE CISCO 3550 PWR SWITCH
C
I Bit rate/Duplex Autosense/ 10 10 100 100
S Autonegotiation
C Mb/s/Half Mb/s/Full Mb/s/Half Mb/s/Full
O
Autosense/ NOK OK OK OK OK
3 Autonegotiation
5
5 10Mb/s/Half Not Tested OK Not Tested Not Tested Not Tested
0
10Mb/s/Full Not Tested Not Tested OK Not Tested Not Tested
P 100Mb/s/Half Not Tested Not Tested Not Tested OK Not Tested
W
R 100Mb/s/Full Not Tested Not Tested Not Tested Not Tested OK
POWER SUPPLY TEST WITH DIFFERENT ETHERNET TWISTED PAIR CABLE LENGTH
The following two cables have been tested and give positive results, i.e., no loss of power supply
noted:
Length 1 meter
Length 90 meters
IP CONFIGURATION OF THE SETS
Alcatel V2 IP Phone have been tested in static IP configuration as well as dynamic IP configuration
(DHCP server on the Alcatel Omni PCX enterprise and IP Phone as DHCP client). The tests are
conclusive in both cases.
TESTS ON CALLS WITH STATION SPEAKER OR HANDS-FREE ACTIVATED
The tests performed are conclusive.
Technical Information: The CISCO 3550 PWR provides 15.4W. An Alcatel V2 IP Phone consumes
4W in normal mode and 5W in hands-free or loudspeaker (estimated as a safety margin -- in
theory, the hands-free or station speaker consumes 10% more power).
SUBJECTIVE VOICE QUALITY TESTS DURING A FILE TRANSFER BETWEEN TWO PCS
Laboratory tests have been carried out to determine the limit of MULTICAST traffic beyond which IP
Phone operation is no longer guaranteed. During the test, voice traffic has been tagged 802.1P, and
the timers which manage the keep-alive mechanism have been set to their default values.
The test results are as follows:
If the 802.1P tagging is configured correctly and supported by the data equipment, the IP set
supports multicast traffic of 90 Mb/s.
In these conditions, it is possible to set up an audio call between an IP Phone and a UA set of
the system without observing any degradation in the audio quality and without the set resetting.
If the data equipment is not configured for 802.1Q tagging, multicast traffic cannot exceed
5 Mb/s.
Set resets may be observed if the data equipment does not guarantee transmission of the keep-
alive mechanism.
Note
During the initialization phase, the IP Phone system exchanges are not tagged at 802.1p level.
Initialization of an IP Phone will not be possible if the multicast traffic is greater than 5 Mb/s.