Sie sind auf Seite 1von 92

TROUBLESHOOTING GUIDE No. TG0014 Ed.

03

OmniPCX 4400/Enterprise Nb of pages : 92 Date : 15 December-2008

SUBJECT: IP PHONES ISSUES

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

1. TROUBLESHOOTING IP PHONES ISSUES .....................................7

2. HISTORY......................................................................................7

3. REFERENCES................................................................................7

4. OPERATING PRINCIPLES ..............................................................8


4.1. Initialization phase ................................................................................... 9
4.1.1. DHCP request ...................................................................................................9
4.1.2. TFTP request ...................................................................................................15
4.1.3. A trace of a complete initialization phase .......................................................24
4.2. Setting up the signaling channel............................................................. 25
4.2.1. Setting up the connection................................................................................26
4.2.2. Maintaining the signaling channel..................................................................27
4.2.3. Keep-alive mechanism, signaling link KO.......................................................29
4.2.4. Data exchange................................................................................................29
4.2.5. Advance data exchange..................................................................................30
4.2.6. Concatenated data exchange .........................................................................30
4.2.7. Signaling link switchover ................................................................................31
4.3. Setting up a call ...................................................................................... 32
4.3.1. IP Phone IP Phone call ..................................................................................32
4.3.2. IP Phone Remote ACT call ............................................................................33
4.3.3. IP Phone Public network call ........................................................................34
4.3.4. Setting up a call ..............................................................................................35

5. STARTING UP THE IP PHONE .....................................................37


5.1. Starting up the IP Phone ......................................................................... 37

6. INVESTIGATIONS WITH THE IP PHONE V2 ................................37

Ed. 03 / 15 December 2008 3 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

6.1. Telnet access........................................................................................... 37


6.2. Help........................................................................................................ 37
6.3. Dialog to IP link ...................................................................................... 38
6.4. Binary version......................................................................................... 38
6.5. Set configuration .................................................................................... 39
6.6. "Ping" command...................................................................................... 40
6.7. Defenses................................................................................................. 40
6.8. UA signaling status................................................................................. 41
6.9. Status and tracking of the audio connection ........................................... 42
6.10. Traces ..................................................................................................... 44
6.11. Trace of the INITPA IP Phone signaling link.......................................... 46
6.12. Trace on DHCP exchanges: DHCP server - IP Phone ............................... 52
6.13. Trace on TFTP exchanges: CPU IP Phone .............................................. 52

7. DIAGNOSTIC HELP ....................................................................54


7.1. IP Phone does not start up: VLAN problem ............................................. 54
7.2. IP Phone does not start up: incorrect configuration of the DHCP server .. 55
7.3. One-directional call/no sound: no router defined................................... 56
7.4. "ippstat" command - A MAC address but no IP address........................... 58
7.5. IP Phone blocked in phase 5-6/6 ............................................................ 60
7.6. Untimely IP Phone reset .......................................................................... 61
7.7. Poor sound quality on callback to busy set.............................................. 63
7.8. Error codes 4.12 and 4.03 appear during the initialization of the IP set.. 64
7.9. Degraded sound quality on IP Phone behind a WAN link ....................... 66
7.10. One-directional call in version V2.11...................................................... 70
7.11. One-directional call in version V2.13...................................................... 71
7.12. "Network down" message: see CDHva55914.......................................... 73
7.13. No "proceed to select" tone ..................................................................... 74
7.14. IP Phone reset with cause "Reset hard requested" / Alarm 378 - Cause 6 75

8. BEFORE CALLING ALCATELS SUPPORT CENTER ........................77

TG0014 4 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

APPENDICES
APPENDIX 1 - STATUS OF THE IP LINK

APPENDIX 2 - ERROR CODES

APPENDIX 3 - NETWORK TRACES

APPENDIX 4 - ADD-ON MODULE

APPENDIX 5 - ALCATEL IP PHONE - CISCO 3550 PWR SWITCH


CATALYST INTERWORKING THROUGH THE "IN LINE
POWER" FUNCTION

APPENDIX 6 - BEHAVIOR OF THE IP PHONE IN THE PRESENCE OF


CONSIDERABLE MULTICAST TRAFFIC

Ed. 03 / 15 December 2008 5 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

TG0014 6 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

1. TROUBLESHOOTING IP PHONES ISSUES


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).

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

IP Phones Technical Characteristics


Available on the BPWS in the section
Support > Technical Support IP Telephony > Technical Knowledge Base > OmniPCX Enterprise >
System Documentation > IP-PCX Networks > IP Phones

Troubleshooting guide N 1 TG0001: Echo in a VoIP environment


Available on the BPWS in the section
Support > Technical Support IP Telephony > Technical Knowledge Base > OmniPCX Enterprise >
Troubleshooting Guides > IP-PCX Networks > Voice over IP

Troubleshooting guide N 2 TG0002: VoIP audio quality problems


Available on the BPWS in the section
Support > Technical Support IP Telephony > Technical Knowledge Base > OmniPCX Enterprise >
Troubleshooting Guides > IP-PCX Networks > Voice over IP

Troubleshooting guide N 15 TG0015: INTIP issues


Available on the BPWS in the section
Support > Technical Support IP Telephony > Technical Knowledge Base > OmniPCX Enterprise >
Troubleshooting Guides > IP-PCX Networks > Voice over IP

Ed. 03 / 15 December 2008 7 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

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).

TG0014 8 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

4.1. Initialization phase

4.1.1. DHCP request


The IP Phone will make a DHCP request to the DHCP servers: an IP set DHCP server link is set up.

Ed. 03 / 15 December 2008 9 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

This step is short-circuited if the IP Phone is configured with a static address.


The IP Phone sends a DHCPDISCOVER request with the aim of obtaining the following information
from a DHCP server present on the network:
The IP address of the IP Phone,
The sub-network mask,
The IP address of the gateway/router,
The IP address of the TFTP server.
The DHCP server can be internal to the OmniPCX or external (as is the case for a DHCP server on
the customer installation site).
If there are several servers present on the network, ALCATEL equipment will have a preference for
Alcatel DHCP servers. The following labels are used in the "vendor class identifier" and "vendor
specific information" optional fields:
"alcatel.tsc-ip.0"
"alcatel.int-ip.0"
"alcatel.a4400.0"
The lease time timer can have a finite or infinite value.
The set will make up to five attempts to obtain a reply from a DHCP server; if no server replies to the
request, the set will reset.
The set must make a request to renew its IP parameters when the lease time timers expire; if these
parameters cannot be renewed, the set resets (without sending a DHCPRELEASE message).
It is essential that DHCP requests (broadcast messages) be resent by a relay DHCP server if the IP set
is not in the same sub-network as the DHCP server.

4.1.1.1. AVA function (under Special Deal Process)


As of system version R5.1 and IP set version V2.18 (integrated IP Phone V2), the DHCP servers can
take the configuration of the VLAN number into account. This should avoid tedious manual
configuration of the VLAN numbers on large installations.
This management must apply through two DHCP servers: the system server and an external server.

TG0014 10 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

The operating principle for assigning VLAN numbers is as follows:

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.

Ed. 03 / 15 December 2008 11 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

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).

4.1.1.1.1. DHCP discover message processing

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:

4.1.1.1.2. DHCP offer message processing

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.

TG0014 12 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

4.1.1.2. A DHCP request trace

The IP address proposed by the


server for the IP Phone

The TFTP server address

The IP Phone has a preference for


the ALCATEL server

Router IP address

Ed. 03 / 15 December 2008 13 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

4.1.1.3. A DHCP request trace and an example of AVA management

The DHCP server proposes a VLAN


number in the DHCP Offer message

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.

TG0014 14 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

4.1.2. TFTP request


The IP Phone will make a TFTP request to the TFTP server: an IP set CPU link is set up.

Ed. 03 / 15 December 2008 15 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

4.1.2.1. IP Phone download management


The TFTP server of the Alcatel OmniPCX is capable of processing up to 24 simultaneous download
requests. The system reserves a TFTP resource for each INTIPA present and declared in the system.
An IP Phone makes a request to download its binary with the option "hsize," it compares the version
of the binary stored on the PABX with its current version, and if it is different the set requests the
loading of the full binary.
The TFTP server manages three scenarios:
For a configuration with less than 100 IP Phones, if a download request cannot be handled
immediately, the server sends an error message with the error code 32000 and the message
"download limit reached." The set will start up with the binary version stored in its memory. After
two minutes of inactivity for the TFTP server, the system runs a procedure for checking the
versions of the IP Phones that have come to make a TFTP request. If the version does not
correspond to the one stored on the server, the server sends a reset order through a UA
message. If the set is being used, the reset is delayed until the end of the call.
If changing the IP Phones binary, and the number of simultaneous requests is very high (50 or
more), the local sub-network will be saturated with TFTP messages (exchanges between clients
and the server) and the response time from the server from an IP set point of view will be severely
degraded. This situation may lead the IP set to interrupt the download of the binary to sequence
directly with the starttscip file, then finish by flashing the binary already loaded in its memory. In
this case the TFTP session will finish without all of the IP Phones having updated their binary. The
same process mentioned in the previous case will be take place and the sets which have not
been able to update the binary will be invited to do so at the systems request.
If a large number of IP Phones are declared on a node, the processing time for the downloading
of new binaries for all of them may become restrictive. In order to improve download speed and
commissioning performance on CPU 5 and CPU 6, the TFTP adopts a global process for large
configurations (100 IP Phones or more), consists of two distinct phases:

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.

TG0014 16 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

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.

4.1.2.2. Limit and default value for the TFTP server


The limits are set as follows:
The TFTP server is capable of managing 24 simultaneous downloads (a resource is reserved
for each INTIPA board declared in the system).
The server can send a maximum of 150 TFTP packets per second.
In the event of a timeout, the server will make five attempts to resend.
The maximum size for the blocks is 1428 bytes.
The default values are as follows:
Timeout value: 5 seconds. This value can be set using the timeout option. It changes during
the download according to the response time of the client (IP set).
Data block size: 512 bytes.

Caution: The IP sets do not accept fragmentation during the download.

4.1.2.3. Error messages sent by the TFTP server


In the event of an error, the TFTP server sends an error frame containing an error code
accompanied by an error message:
Code 0: TFTP request is not read type,
Code 0: TFTP request with an unknown transfer mode (different from byte or netascii),
Code 1: File cannot be found (or is impossible to generate),
Code 2: Incorrect access rights to the file (file read permission absent for owner, group
or other),
Code 4: Illegal TFTP operation (error in the message),
Code 32000: Download limit reached ( 24 downloads in progress),
Code 32001: Non-volatiles unavailable,
Code 32002: INTIP not declared (failure of the check that the board belongs to the node on
which the TFTP server is running),

Ed. 03 / 15 December 2008 17 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

Code 32003: Access error, relative path in the request,


Code 32004: Access error, incomplete path without Ethernet address specified,
Code 32005: Access error, path invalid (different from /bootp or /DHS3bin/downbin)
Code 32006: Access error, non-absolute path for a standard file,
Code 32007: Access error, starttscip file requested with an Ethernet address that is not in
TSCIP format (MAC address + sub-address),
Code 32008: Access error, startintip file requested with an Ethernet address that is not in
INTIP format (MAC address in standard format),
Code 32009: No file descriptor available on the CPU,
Code 32010: No recording equipment declared for the IP Phone,
Code 32011: No recording equipment available for the IP Phone,
Code 32012: No more sockets available on the CPU,
Code 32013: Immediate start-up order without downloading the binary.

4.1.2.4. Download time


Download time from a CPU5/CPU6 with a configuration of less than 100 IP Phones.

Number of IP Phones reset With download Without download


1 1 minute 20 seconds
21 2 minutes 40 seconds
82 8 minutes 53 seconds

Download time from a CPU5/CPU6 with a configuration with at least 100 IP Phones.

Number of IP Phones reset With download Without download


1 1 minute 17 seconds
21 6 minutes 41 seconds
82 14 minutes 49 seconds
400 1 hour (*) 3 minutes (*)
1000 2 hours 30 minutes (*) 6 minutes (*)
4000 10 hours (*) 23 minutes (*)

(*) These results are obtained by extrapolation.

TG0014 18 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

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.

4.1.2.4.2. Binaries used

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).

Ed. 03 / 15 December 2008 19 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

The following rights must be validated for the binary files:


(1)krk> ls -l binipph1
-rw-r--r-- 1 mtcl tel 344651 Dec 11 2002 binipph1

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.

TG0014 20 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

An example of loading the binary header only:

Request to download binary


binipph1

Option: hsize

System response: binipph1


version 2.13

Ed. 03 / 15 December 2008 21 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

An example of loading the complete binary:

1st download request, the set compares


the file header with its binary

2nd request, the set requests the binary in


blocks of 1428 bytes

........................................................

Loading request, the hsize option is


not set!

The header + the binary

TG0014 22 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

4.1.2.4.3. "Starttscip" file


starttscip: file in ASCII format
UDP_PORT_SIG = x
x is the UDP port specified in the system options.
On the last TFTP transfer initiated by the IP Phone, the IP Phone makes a request to download the
"starttscip" file. Through this file, the Alcatel OmniPCX gives the set the address of the UDP port that it
will have to use during system exchanges with the INTIPA board. The address of the UDP port used
by the INTIPA is allocated dynamically when setting up the UA connection.

An example of downloading the "starttscip" file:


Request to download the
"starttscip" file

Address of the UDP port to use

Ed. 03 / 15 December 2008 23 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

4.1.3. A trace of a complete initialization phase


In the following sniffer trace, the different steps in the IP Phone start-up can be noted:
DHCP requests
Router ping
TFTP requests (loading of three files "lanpbx.cfg," "binipph1" and "starttscip")
Setting up the signaling channel

TG0014 24 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

4.2. Setting up the signaling channel

Ed. 03 / 15 December 2008 25 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

4.2.1. Setting up the connection


The CPU asks the INTIPA to set up the signaling channel to the IP Phone.
The INTIPA initiates setting up the signaling channel. The INTIPA is responsible for opening the
INTIPA port to the IP Phone and the IP Phone is responsible for opening the port from the IP Phone to
the INTIPA. The IP Phone must send a connect message after sending its connect_ack message. The
IP Phone must wait for the connect_ack in return before sending the first data.

Connection phase trace:

UDP D=32000 S=32640 LEN=31


UDP UA MESSAGE - DHS => SET
CONNECT - 0x00
Version 1 - 0x01
Window size 1 - 0x01
MTU 2 - 0x04 0x00
UDP lost 1 - 0x0a
UDP lost reinit 1 - 0x07
UDP keepalive 1 - 0x03
QOS ip tos 1 - 0x00
UDP D=32640 S=32000 LEN=9
UDP UA MESSAGE - SET => DHS
CONNECT ACK - 0x01
UDP D=32640 S=32000 LEN=31
UDP UA MESSAGE - SET => DHS
CONNECT - 0x00
Version 1 - 0x01
Window size 1 - 0x01
MTU 2 - 0x04 0x00
UDP lost 1 - 0x0a
UDP lost reinit 1 - 0x07
UDP keepalive 1 - 0x03
QOS ip tos 1 - 0x00
UDP D=32000 S=32640 LEN=9
UDP UA MESSAGE - DHS => SET
CONNECT ACK - 0x01

TG0014 26 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

4.2.2. Maintaining the signaling channel


The INTIPA and the IP Phone control the signaling channel. The check involves ensuring the correct
sequencing of the DATA packets and, if necessary, resending them if there is an acknowledgement
fault. The packet sequence check is carried out at the application level (the unconnected UDP
protocol does not allow this check).
In the absence of data to send, the INTIPA sends KEEPALIVE packets that the remote IP Phone must
acknowledge through KEEPALIVE_ACK packets. KEEPALIVE messages are sent every three seconds.
The sending of the first KEEPALIVE message by the INTIPA board starts three seconds after the end of
the last DATA transmission. The clocks of the INTIPA boards and the IP Phones are not synchronized.
The date and the time are sent to the INTIPA board and to the IP Phone during the initialization
phases and once a day at midnight. This information is not configured locally on the coupler. For the
IP Phone, this information is managed locally and corresponds to the information displayed on the
set.
The principle of the KEEPALIVE-KEEPALIVE_ACK mechanism is to check for the presence of the link
between an INTIPA board and the IP Phone. The UDP protocol and the implemented mechanism do
not allow packet sequence to be checked. A KEEPALIVE_ACK received is always considered an
acknowledgement of the last KEEPALIVE message sent.
The UDP_Keep_Alive, UDP_LOST and UDP_LOST_REINIT timers govern management of the IP
Phone and INTIPA signaling link and the KEEPALIVE-KEEPALIVE_ACK mechanism. These parameters
are accessible by MGR. The default values are set as:
UDP_Keep_Alive = 3 seconds,
UDP_LOST = 7 seconds,
Distant_UDP_LOST = 10 (seconds),
This timer is not available for modification; it is an internal timer for the IP Phone that
appears in certain system traces:
Distant_UDP_LOST= UDP_Keep_Alive + UDP_LOST
UDP_LOST_REINIT = 7 seconds,
Note
It is strongly advised not to modify the value of these parameters.
If a DATA packet or a KEEPALIVE is not acknowledged, a retransmission mechanism takes place. The
packet is resent a first time 200 milliseconds after the first unacknowledged transmission. It is then
resent every second. All counters are reset on receipt of a KEEPALIVE_ACK message and the normal
KEEPALIVE transmission mechanism resumes until the next no reply.
Out of context, an INTIPA IP Phone link can be considered OK if one KEEPALIVE_ACK message is
received for seven KEEPALIVE messages sent.
The signaling channel is closed on the INTIPA if the UDP_LOST timer expires.

Ed. 03 / 15 December 2008 27 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

Keep-alive mechanism, signaling link OK:

Keep-alive sequence
UDP D=32000 S=32640 LEN=9
1 - 0x04
UDP UA MESSAGE - DHS => SET
KEEPALIVE - 0x04

UDP D=32640 S=32000 LEN=9


1 - 0x05
UDP UA MESSAGE - SET => DHS
KEEPALIVE ACK - 0x05

UDP D=32000 S=32640 LEN=9


1 - 0x04
UDP UA MESSAGE - DHS => SET
KEEPALIVE - 0x04

UDP D=32640 S=32000 LEN=9


1 - 0x05
UDP UA MESSAGE - SET => DHS
KEEPALIVE ACK - 0x05

TG0014 28 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

4.2.3. Keep-alive mechanism, signaling link KO

4.2.4. Data exchange


The image below shows the exchange of data between INTIP and IP Phone.

Ed. 03 / 15 December 2008 29 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

4.2.5. Advance data exchange


The INTIPA is able to send data in advance. Packets can be sent by the INTIPA before the
acknowledgements for the previous messages are received. The IP Phone must forward an
acknowledgement for each message received, based on the sequence number received. Upon
receipt of a NACK message, the INTIPA forwards all the packets sent from the faulty sequence
number.
The advance data sending function does not exist in the IP Phone.

4.2.6. Concatenated data exchange


The INTIPA can concatenate several UA messages in a single data packet. The transmission of this
type of message is comparable to the exchange of a single UA message.
Example of a concatenated data exchange:

TG0014 30 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

D=32000 S=32640 LEN=80


UDP UA MESSAGE - DHS => SET
DATA - 0x07
Expected sequence number 5
Sent sequence number 5
UA MESSAGE - DHS => SET - Length 25
LCD LINE 2 COMMAND - 0x28
Command : Write from column
LCD options : No blink, do not change call timer
status, do not display call timer,
do not display time of day,
suspend display refresh
Column number : 0
Content : 20 - 0xff 0x20 0x2e 0x2e 0x2e 0x2e 0x20 0x20
0x20 0x20 0x2e 0x2e 0x2e 0x2e 0x20
0x20 0x20 0x20 0x2e 0x2e
Content : 20 - ' .... .... ..'
UA MESSAGE - DHS => SET - Length 25
LCD LINE 2 COMMAND - 0x28
Command : Append to line
LCD options : No blink, do not change call timer
status, do not display call timer,
do not display time of day,
refresh display
Column number : 0
Content : 20 - 0x2e 0x2e 0x20 0x20 0x20 0x20 0x2e 0x2e
0x2e 0x2e 0x20 0x20 0x20 0x20 0x2e 0x2e
0x2e 0x2e 0x20 0xfe
Content : 20 - '.. .... .... '
UA MESSAGE - DHS => SET - Length 13
LCD LINE 1 COMMAND - 0x27
Command : Clear line and write from column
LCD options : No blink, do not change call timer
status, do not display call timer,
display time of day, refresh
Display Column number : 24
Content : 8 - 0x31 0x36 0x2f 0x30 0x34 0x2f 0x30 0x32
Content : 8 - '16/04/02'
UA MESSAGE - DHS => SET - Length 4
IP DEVICE ROUTING CODE - 0x13
Command : 0x06 -> Stop tone generation
UDP D=32640 S=32000 LEN=13
UDP UA MESSAGE - SET => DHS
DATA - 0x07
Expected sequence number 6
Sent sequence number 4

4.2.7. Signaling link switchover


In the event of the loss of a signaling link and if a second INTIPA board is present, the system
attempts to switch over the signaling link to the second INTIPA during the UDP_LOST_REINIT phase.
The signaling link switchover mechanism is identical to the signaling link switchover to INTIPB.

Ed. 03 / 15 December 2008 31 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

4.3. Setting up a call

4.3.1. IP Phone IP Phone call

TG0014 32 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

4.3.2. IP Phone Remote ACT call

Ed. 03 / 15 December 2008 33 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

4.3.3. IP Phone Public network call

TG0014 34 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

4.3.4. Setting up a call

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.

Ed. 03 / 15 December 2008 35 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

UDP UA MESSAGE - DHS => SET


DATA - 0x07
Expected sequence number 11
Sent sequence number 12
UA MESSAGE - DHS => SET - Length 40
IP DEVICE ROUTING CODE - 0x13
Command : 0x01 -> Start RTP
Direction 0x02 -> IP-Phone input and output
Local UDP port - 0x00
2 - 0x7d 0x02 - 32002
Remote IP address - 0x01
4 - 192 168 65 41
Remote UDP port - 0x02
2 - 0x7f 0x60 - 32608
Type of service - 0x03
1 - 0x00
Compressor - 0x04
1 - 0x10 -> G.723.1 6.3 kbps
Payload concatenation - 0x05
1 - 0x1e
Echo cancelation - 0x06
1 - 0x01
Silence compression enabler - 0x07
1 - 0x00
Post filtering - 0x0a
1 - 0x01
High pass filtering - 0x0b
1 - 0x01

..
[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

TG0014 36 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

5. STARTING UP THE IP PHONE

5.1. Starting up the IP Phone


The IP Phone goes through six steps in its initialization phase:
1/6: Initialization of the IP link (set in static/dynamic mode)
2/6: IP parameter contact with DHCP server
3/6: Loading of "lanpbx.cfg" file
4/6: Loading of "binipph1" binary file
5/6: Copying binary to flash memory
6/6: Loading of "starttscip" file
Setting up the UA signaling link
If the progression is stopped, an error is signaled, details are available by consulting the "status info"
parameter.
To access "status info," the following keys on the set must be pressed successively:
[i]/MENU, then #, then 4 "misc" and 1 "status info."

6. INVESTIGATIONS WITH THE IP PHONE V2

6.1. Telnet access


A telnet connection in an IP Phone can be made from the Main or Standby CPU of the Alcatel
OmniPCX4400 as long as their respective IP addresses have been declared in the lanpbx.cfg file
(see IP_CPU1 and IP_CPU2).
(1)krk> telnet 192.168.65.91
Trying 192.168.65.91...
Connected to 192.168.65.91.
Escape character is '^]'.
IpPhone >

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
.....

Ed. 03 / 15 December 2008 37 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

25 redirect flux direction


flux: all
|debug|trace|rtp|jitter|rtcp|ua|ua_msg|dsp|eim|mgr|supervisor|init|display|kbd|aom
direction: telnet(=eth)|v24
.....
33 ua [stats] | help | version
34 uptime: time elapsed from set powering
.....
38 voice
voice d2n|n2d|jitter|usage|txnob
voice +|-
voice out|red|yellow|green threshold
help OK

6.3. Dialog to IP link


In the IP Phone, the default communication port is the integrated V24 port; this port is not available
or accessible by default. The call flow must be redirected towards the IP link.
IpPhone > help redirect
help redirect
IpPhone > redirect flux direction
flux: all
|debug|trace|rtp|jitter|rtcp|ua|ua_msg|dsp|eim|mgr|supervisor|init|display|kbd|aom
direction: telnet(=eth)|v24

The redirect command allows all of the all flows to be redirected towards the "eth" interface.

IpPhone > redirect all eth


redirect all eth
IpPhone > redirect OK

6.4. Binary version


The id command allows the version of the binaries loaded in the IP Phone to be checked. In the
following example, the IP Phone version is 2.13.
IpPhone > id
id
IpPhone > arm : 2.13.00
arm boot : 2.00.03
dsp : 07.17 (running 07.17)
dsp bios : Fri Jul 26 17:55:05 2002-config.cdb-@(#)*** glue-d09-
boot dsp : b0.02
nucleus plus: 1.13.21
nucleus net : 4.4.8
nucleus snmp: 1.3.3
orion : 30
G729AB ENCODE/DECODE FAR: 54.3.2.5
G723A ENCODER FAR: 54.3.1.4
G723A DECODER FAR: 54.3.1.4
LINK DATE: Mon Dec 9 17:33:42 MET 2002
LINK PATH: /users/ip_phone/tw_src/r_release2
id OK

TG0014 38 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

6.5. Set configuration


The config command gives a summary of the IP Phone configuration. It allows the IP parameters to
be checked: the set address (local addr), the sub-network mask (SubNetMAsk), the router address
(Router), and the TFTP server coordinates (TFTP addr). The "VLAN using" parameter states whether
the quality of service 802.1q is activated.
The configuration of the switch ports is given by "Ethernet: LAN" and "Ethernet: PC."
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 : 192.168.65.1 192.168.65.1
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
The IP Phone internally manages two types of configuration, one configuration saved in the flash
memory ("flash") and the active configuration ("current").
There are two scenarios:
The IP Phone is configured in static mode:
The parameters stored in the flash memory are the ones programmed by the operator: IP
parameters ("Local addr, SubNetMask, Router, Tftp addr"), VLAN number ("VLAN id"), QOS
level 2 802.1q ("VLAN using"), and state of the ethernet link ("Ethernet LAN: PC:").
The current parameters are identical to those stored in the flash memory with one exception,
the "ethernet LAN: xxx PC: xxx" parameter of the active configuration gives the current state of
the Ethernet link after auto-negotiation with the opposite part (LAN = 100/Half, no PC
connected on the switch of the IP Phone).
The IP Phone is configured in dynamic mode:
Only the parameters stored in the flash memory: VLAN number ("VLAN id"), QOS level 2
802.1q ("VLAN using"), state of the Ethernet link ("Ethernet LAN: PC:") are significant. These
parameters must be configured by an operator. As of version 2.18 of the V2 IP Phone and
version R5.1 of the Alcatel OmniPCX-enterprise, it will be possible for the DHCP server of the
system to assign the VLAN number ("VLAN id") dynamically (see the AVA function).
The IP parameters ("Local addr, SubNetMask, Router, Tftp addr") of the active configuration
are assigned by the DHCP server and may be different from the parameters indicated in the
flash configuration.
The management of the other parameters is identical to that described in static mode.

Ed. 03 / 15 December 2008 39 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

6.6. "Ping" command


The ping command can be run from the IP set. This allows the access to different routes to be
checked:
IP Phone to IP Phone of the same sub-network, or to different sub-networks,
IP Phone to INTIPA or INTIPB boards,
IP Phone to the DHCP and TFTP servers,
IP Phone to the CPU of the Alcatel OmniPCX,
IP Phone to the router,
Before running the command, be sure that the data flow sent by the IP set is directed towards the IP
link; to do this run the following command:
IpPhone > redirect all eth
redirect all eth
IpPhone > redirect OK

An example of the set successfully receiving an ICMP reply message: ping ok


IpPhone > ping 192.168.65.91
ping 192.168.65.91
IpPhone > 000-23:37:03.620 ping 192.168.65.91 OK

An example of the set not receiving an ICMP reply message: ping ko


Caution: Be patient, the "ping 192.168.65.2 KO" reply is only displayed after the ping
command timeout.
IpPhone > ping 192.168.65.2
ping 192.168.65.2
IpPhone > 000-23:37:55.000 ping 192.168.65.2 KO

6.7. Defenses
The uptime command shows how long an IP Phone has been operational.

IpPhone > uptime


uptime
IpPhone > uptime: set is up since 0 day 1 hour 30 minutes 35 seconds
uptime OK

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

TG0014 40 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

-......
-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

Messages reported when a set is reset can be interpreted as follows:

000 001-14:58:29.250 reset hard requested

Error message label

Time elapsed since penultimate (next-to-last) reset (commissioning)


001 days 14 hours: 58 minutes: 29 seconds.250 hundredths

Last error that was reported


The table below summarizes the main reset causes reported by the V2 IP Phone.

Reset hard requested IP link lost,


Lease not renewed (dynamic configuration)
Reset hard requested by TSC protocol Reset hard request by the system
Reset hard dwl step: flashing, status: SUCCESS
Reset hard requested by supervisor
Uart lost 10

6.8. UA signaling status


The IP Phones store the statistics which allow the UA signaling link to be qualified in their memory.
The UA command which is run after the telnet in the IP set displays the statistics.

Ed. 03 / 15 December 2008 41 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

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

6.9. Status and tracking of the audio connection


Debug commands allow investigations into voice quality problems to be performed. This involves the
voice command, which can be activated with or without parameters.
The IP Phone is idle; no audio call is set up:
IpPhone > voice
voice
IpPhone > session 0 not active
session 1 not active
voice OK

An audio call is set up:


IpPhone > voice
voice
IpPhone > session 0:
G723.1_6.3k no VAD tx(1*30ms) rx(1*30ms)
local (192.168.65.91:32002, SSRC=0x004dd44d)
remote (192.168.65.93:32040, SSRC=0x6eb4cae7)
duration (000-00:01:06.840 )
session 1 not active
voice 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)".

TG0014 42 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

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

Information relating to the RTP statistics:


seqnum:
Corresponds to the RTP packet sequence number.
total:
Counts the number of RTP packets received.
dsp lost:
Samples which have not been sent to the signal processor.
rtp lost:
Number of RTP packets not received by the set. Loss of an RTP packet is detected from the
moment that the RTP sequence numbers are not consecutive.
voice frame:
Equal to the number of RTP packets containing speech samples (the distinction is made
between DTMF, FAX, etc. packets).

Ed. 03 / 15 December 2008 43 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

Information relating to the DSP statistics:


total request:
Number of samples needed by the signal processor since setting up the audio channel. This
number may be larger than the number of RTP frames received; internally DSP activation is
not synchronized with setting up the RTP layer.
total ok:
Number of samples effectively received by the signal processor.
miss late/lost:
Samples received too late or lost.
bfi:
Number of "Bad Frame Interpolation," number of samples that the signal processor has to
simulate (as they have not been received).
bfi cons max:
Maximum number of successive "bfi": indicates a time slot for which the DSP is obliged to
place a "blank" to simulate missing samples.
The relation between the number of DSP samples and the number of RTP frames received depends
on the "framing" and the type of compression configured:
G723: framing = 30 milliseconds --> an RTP packet contains one DSP sample.
G729 / G711: framing = 30 milliseconds --> an RTP packet contains three DSP samples.
G729 / G711: framing = 20 milliseconds --> an RTP packet contains two DSP samples.
In the example given as a reference, the set makes a call in G723.
In the transmission direction, the IP Phone counts the number of DSP and RTP frames sent.
IpPhone > voice d2n
voice d2n
IpPhone > DSP_to_NET:
rtp
seqnum 28265
total 41267
sid 0
silence 0
dsp
total 41267
queue full 0
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.

TG0014 44 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

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
................

The UA trace is stopped using the following command:

level ua 999
level ua 999
IpPhone > level OK

Below, the traces are activated for all the flows:


IpPhone > level all 0
level all 0
IpPhone > level OK
000-03:47:47.160 RTCP___: rtt= 18ms max= 74ms (dist[0]=1562)
000-03:47:48.050 58556 263770 40 263768 0 0 [ 1 1.0, 50 50 0 0] -
7588 -9 80 27
000-03:47:48.290 ua_udp: received KEEPALIVE
000-03:47:48.290 ua_udp: ua_udp_timer_link_lost_run()
000-03:47:51.050 58656 263870 40 263868 0 0 [ 1 1.0, 50 50 0 0] -
7836 -9 80 25
000-03:47:51.390 ua_udp: received KEEPALIVE
000-03:47:51.390 ua_udp: ua_udp_timer_link_lost_run()
000-03:47:52.180 RTCP___: rtt= 16ms max= 74ms (dist[0]=1563)

Ed. 03 / 15 December 2008 45 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

000-03:47:54.050 58756 263970 40 263968 0 0 [ 1 1.0, 50 50 0 0] -8096


-10 79 27
000-03:47:54.490 ua_udp: received KEEPALIVE
000-03:47:54.490 ua_udp: ua_udp_timer_link_lost_run()

level all 999


level all 999
IpPhone > level OK

6.11. Trace of the INITPA IP Phone signaling link


It is possible to trace the INTIPA to IP Phone signaling link by setting traces in the INTIPA board. For
more information on these traces, see the troubleshooting guide on the INTIP.
To set a trace in the INTIPA board, you must be connected on "mtch" ("mtch" on Alcatel OmniPCXs in
versions below 5.1; in 5.1 cpl_online connection on INTIPA is possible on "mtcl").
(1)krk> su - mtch
Password: xxxxxxxx
# The role of the CPU is MAIN
Application software identity
R5.0Ux-d2.313-7-l-fr-c6s2
Business identification: R5.0Ux
Release:
DELIVERY d2.313
Patch identification: 7
Dynamic patch identification: l
Country: fr
Cpu: c6s2
ACD VERSION
release : 4
bug_fixing : 4
protocol_id : 75
version_dy_hr_stat : 11
System voice guides : v4.1

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

DISPLAY DOMAIN INFO Menu


--------------------------------
Display one Domain :1
Display all Domains :2
Display one Entry :3
Display all Domains Entries :4
Display one Domain Entries :5
Display IP Hash Table :6
Display one Domain Devices :7
Display all Domains Devices :8
Quit this tool :0

Enter your choice : 8


-------------IP couplers defined in domain 0 DEFAULT_DOM-------------

TG0014 46 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

+--------+--------+-------+-----------------------+-----------------+
| 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|
+--------+--------------+--------------------+-+-----+---------------+----+

In the single column


V: means the channel is valid
-: means the channel is not valid

-------------IP couplers defined in domain 1 IP_REMOTE-------------


+--------+--------+-------+-----------------------+-----------------+
| Type | Cr/Cpl | Neqt | Mac Address | Ip Address |
+--------+--------+-------+-----------------------+-----------------+
| INTIPB| 3/ 6 | 10245 | 00:80:9f:04:c8:67 | 192.168.065.176|
+--------+--------+-------+-----------------------+-----------------+
----------------------IP Terminals in domain 1 IP_REMOTE ------------
NOTHING
return to menu : press ENTER

The ippstat command identifies the INTIPA board that manages the signaling channel of a given
IP set.
(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
Display an IP Phone Board structure : 6
Display all IP Phone Board structure : 7
Display all Mac Address Used : 8
Display IP Phone by adr mac/adr adr ip/mcdu : 9
Display all IP Phones connected on a board : 10
Display all IP Phones connected with boards : 11
Ip Phone download Menu : 12
INT IP Menu : 13
Domain Menu : 14
Status Menu : 15
Quit this tool : 0

Enter your choice : 11

Ed. 03 / 15 December 2008 47 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

Coupler INTIPA cr 0, cpl 4, Ghost Eqt 10244


+--------+--------------+--------------------+-+-----+---------------+----+
| QMCDU | Name | Mac Address | |Neqt | Ip Address |Type|
+--------+--------------+--------------------+-+-----+---------------+----+
|31051 |31051 |00:80:9f:3b:6e:32:00|S|00471|192.168.065.178| V1S|
+--------+--------------+--------------------+-+-----+---------------+----+

In the single column


S: means sig. channel is supported by this board for these IP Phones
V: means voice channel is supported by this board for these IP Phones
B: means both channel is supported by this board for these IP Phones

Actually this board supports 01 signaling links


Actually this board supports 00 voice connections
Actually this board supports 00 both signaling and voice

Next board: press ENTER


Coupler INTIPA cr 0, cpl 18, Ghost Eqt 10251
+--------+--------------+--------------------+-+-----+---------------+----+
| QMCDU | Name | Mac Address | |Neqt | Ip Address |Type|
+--------+--------------+--------------------+-+-----+---------------+----+
|31050 |31050 |00:80:9f:3d:00:dc:00|S|00470|192.168.065.182|Intg|
+--------+--------------+--------------------+-+-----+---------------+----+

In the single column


S: means sig. channel is supported by this board for these IP Phones
V: means voice channel is supported by this board for these IP Phones
B: means both channel is supported by this board for these IP Phones

Actually this board supports 01 signaling links


Actually this board supports 00 voice connections
Actually this board supports 00 both signaling and voice

return to menu : press ENTER

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'

Access the TSC IP or IP Phone menu:


INTIP:tscip

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.

TG0014 48 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

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

(0) Clear flag


(1) Discard reception : Not implemented
(2) Discard transmission: Not implemented
(3) Loopback (up) : Not implemented
(4) Trace : 1
(5) Extended trace : 0
(6) Debug mode : 0

Your choice ? :5
000005A1-1CE33406: End of command execution

The trace starts after initialization of a set:


TSCIP:
TSCIP:
000005A2-1CE36FD1: DL_0x00:(Wait 0000, Tx 0000) - Tx CONNECT
(0017) 00 00 01 01 01 01 01 02 02 04 00 03 01 0A 04 01
07 05 01 03 06 01 00
000005A3-1CE36FFA: DL_0x00:(Wait 0000, Tx 0000) - Tx CONNECT
(0017) 00 00 01 01 01 01 01 02 02 04 00 03 01 0A 04 01
07 05 01 03 06 01 00
000005A4-1CE36FFA: DL_0x00:(Wait 0000, Tx 0000) - Rx CONNECT_ACK
000005A5-1CE36FFA: DL_Ox00: Link state event 1 (reason 8)
000005A6-1CE36FFA: DL_0x00:(Wait 0000, Tx 0000) - Rx CONNECT -> msg_session 0000
dl_session 0000
(0017) 00 00 01 01 01 01 01 02 02 04 00 03 01 0A 04 01
07 05 01 03 06 01 00
000005A7-1CE36FFA: Dl_0x00:(Wait 0000, Tx 0000) - Rx CONNECT -> Tx CONNECT_ACK
(0001) 01
000005A8-1CE37001: FL_0x00:(Wait 0000, Tx 0000) - Rx DATA (Rx 0000, Ack 0000)
000005A9-1CE37001: DL_0x00:(Wait 0000, Tx 0000) - ack_test : ack_num_seq=0,
last_ack_num_seq=0, sent
_msgs_no_ack=0 -> OK1
000005AA-1CE3700C: DL_0x00:(Wait 0001, Tx 0000) - Tx DATA
(0078) 07 00 01 00 00 27 00 13 04 06 01 B8 EC 00 00 00
01 4A EE 00 00 00 01 4A F2 01 B8 EC 01 B8 E8 00

Ed. 03 / 15 December 2008 49 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

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

TG0014 50 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

..................
..................
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)

DL_LINK: Dump of dl_link number 0


Distant info :
- Distant ip address = 192.168. 65.182 (C0A841B6)
- Distant UDP port = 32000 (7D00)
DL connect struct :
- Version Number = 1
- Window Size = 1
- Mtu Size = 1024 (bytes)
- Udp Lost = 7 (seconds)
- Distant Udp Lost = 10 (seconds)
- Udp Lost Reinit = 7 (seconds)
- Keepalive = 3 (seconds)
- Source Udp Port = 32640
- Local TOS/Diffserv = 00
- Local 802.1 tagging = No
- Distant TOS/Diffserv = 00
- Distant 802.1 tagging = No
- session_id = No SESSION
Dump of DL Seq :
- Tx seq num = 5
- Rx seq num = 5
- Ack seq num waited by distant = 5
- Last ack seq num sent to distant = 5
- Current number of messages sent and not ack = 0
- Last DISTANT seq nack by coupler = 0 (0 times)
- Last LOCAL seq nack by distant = 0 (0 times)
Dump of DL Stats :
- Average stats :
- Total bytes to send = 307
- Total bytes sent = 307
- Payload effectiveness ratio = 100%
- Total messages to send = 9
- Total messages sent = 5
- Message number effectiveness ratio = 180%
- Instant stats : (Integration period of 30 sec.)
- Bytes to send rate = 0 bytes/sec

Ed. 03 / 15 December 2008 51 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

- Bytes sent rate = 0 bytes/sec


- Messages to send rate = 0 msg/sec
- Messages sent rate = 0 msg/sec
FASTSK Object :
Source TSAP : 192.168.65.105:32640 (0xc0a84169:0x7f80)
Destination TSAP : 192.168.65.182:32000 (0xc0a841b6:0x7d00)
Default router : 192.168.65.1 (0xc0a84101)
Destination MAC : 00:80:9F:3D:00:DC
FASTSK QOS Conf :
# No QOS
FASTSK Stat :
# UDP Fast Socket
# - Status : EISVALID
# - Tx Packets : 86
# - Rx Packets : 78
# - Nb ARP : 2
# - Nb ICMP DestU : 1
Dump DL incident :
22/08 05:35:31 - State of the link changed to LINK_UP
22/08 05:39:07 - Keepalive lost
22/08 05:39:08 - Keepalive lost
22/08 05:39:09 - Keepalive lost
22/08 05:39:10 - Keepalive lost
22/08 05:39:11 - Keepalive lost
22/08 05:39:12 - Keepalive lost
22/08 05:39:13 - Keepalive lost
22/08 05:39:13 - State of the link changed to LINK_DOWN
Non ack message pool :
Non sent message pool :

6.12. Trace on DHCP exchanges: DHCP server - IP Phone


To be described.

6.13. Trace on TFTP exchanges: CPU IP Phone


To be described.

TG0014 52 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

History of V2 IP Phone versions.

Major problem: one-directional call observed mainly in an


Alcatel OmniPCX Enterprise environment associated with
network disturbances (anomaly report CDHva58570).

The problem can be evident from a sniffer trace: the IP Phone


Released version sends RTP frames with silence code D5, D4, or 55. Version
V2.13 corrects this problem.

Major problem: one-directional call in G711 without VAD


with a framing of 20 ms (anomaly reports XTSce08021and
Released version XTSce08021).

The problem can be evident from a sniffer trace: the IP


Phone stops sending and the last RTP frame is too short
(two bytes missing). Version V2.16 corrects this problem.

No blocking point identified to


date.
R&D
version The version integrates the one-
directional call problem
beta test correction identified in version
version V2.13

On this version and previous


ones, it is not possible to
return to an older version.

This version integrates the corrections of all


known blocking points and the new "AVA"
function: Automatic VLAN Assignment.

Released This version allows returns to a previous


version version.

Ed. 03 / 15 December 2008 53 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

7. DIAGNOSTIC HELP

7.1. IP Phone does not start up: VLAN problem


Problem
IP Phone does not start up; the set remains blocked in phase 2/6 or 3/6.
Symptoms
In dynamic mode, the IP Phone remains blocked in state 2/6 after a timeout, and displays
the following error message:
2.02 (Retry after error while getting IP params in dynamic mode)
In static mode, the IP Phone remains blocked in state 3/6, and depending on the progress of
the initialization, displays the following errors:
2.08 (Router not responding to ping)
3.11 (TFTP server is not running)
3.02 (Retry after error during config file loading)
Analysis and Explanation
This has been observed when there is a difference between quality of service setting and the data
network configuration.
Solution
Check the set configuration to see whether the Level 2 quality of service is correctly set and in line
with the data network configuration. Check whether:
VLAN is "activated/deactivated",
VLAN ID if VLAN is activated.
Example
If VLAN is set to "activated" on the set but the VLANs are not configured on the network, the tagged
frames of the IP Phone will never reach their recipients. The set will never receive a reply from the
router, the DHCP server or the TFTP server.
In the following trace, the set makes DHCP requests, and no server replies; the frames are tagged
802.1Q in transmission, but the network does not manage QOS level 2.

TG0014 54 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

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.

Ed. 03 / 15 December 2008 55 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

7.3. One-directional call/no sound: no router defined


Problem
IP Phone in call, no sound in one direction.
Symptoms
In the configuration described below, IP Phone A sets up a call with the DECT set, the two sets
are in communication, and the call duration information is incremented, but there is no sound in
the IP Phone-to-DECT-set direction.
Analysis and Explanation
As a reminder, the IP Phone in communication must set up two links: an IP link for signaling
(link set up with the INTIPA board) and an IP link for the audio call (link to be set up with the
INTIPB board).
The audio link is set up after receiving the UA start RTP message. This link cannot be set up if
IP Phone A does not find the path to the INTIPB. The set must know the address of router A.

Likewise, router A should be configured so that it knows the route to the INTIPB.

The IP Phone A is communicating with the DECT or


PWT set; no sound received at DECT/PWT end

DECT set

The address of this router is


unknown to the IP phone A

TG0014 56 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

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.

Ed. 03 / 15 December 2008 57 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

7.4. "ippstat" command - A MAC address but no IP address


Problem
Sets are registered in a system without an IP address. The system declares the sets as V1 TSCIP
sets.
Symptom
When running the "ippstat" command, which allows all the IP sets of the installation to be
displayed, sets may appear as V1 TSCIP sets with a MAC address but without an IP address.
Analysis and Explanation
This phenomenon is observed after a system shutdown.
The IP Phones which appear with a MAC address without IP addresses are sets which have been
physically disconnected from the system without going through the de-registration procedure.
These sets do not register themselves after the TFTP server is restarted. The system has kept the
MAC address associated with a directory number in memory.
Example
(1)krk> ippstat d 4943

Logic coupler type : CPL_UA


MAO coupler type : UA_FICTIF
Coupler state : IN SERVICE
Terminal state : OUT OF SERVICE
Terminal type : IP PHONE
+----------------------------------------------------------------------------+
| Cry:Cpl:ac:term | neqt |nulog| typ term | dir nb | Out of service cause |
+----------------------------------------------------------------------------+
| 19 2 0 3 | 1188 | 375|4035(MR2_3| 4943 | A . . . . . . . . . |
+----------------------------------------------------------------------------+
|A: att_mserv, C: hs_defich, I: hs_isolauto, X: hs_isolman, T: hs_terdef |
|U: hs_usdef, P: hs_errparite, B: hs_bascul, Y: hs_cristisol, N: hs_inex |
+----------------------------------------------------------------------------+
+----+--------------------+-+-----+-------+----------+---------------+----+
|Indx| Mac Address | |Neqt | QMCDU | Name | Ip Address |Type|
+----+--------------------+-+-----+-------+----------+---------------+----+
|0307|00:80:9f:3b:d2:b9:00|-|01188|4943 |FRANCAIS H|000.000.000.000| V1 |
|Sign| 255/255 | |NoCnx| ON CPL| | | |
+----+--------------------+-+-----+-------+----------+---------------+----+
Ip domain is : 0
Ip Voice Coding is IntraDom G711 : ExtraDom G711
QOS parameters for category 7:
DSCP diffserv : 46
802.1Q used Yes
Vlan Identifier (Vid) : 46
User priority (8021Q pri.) : 5
Firmware version is Unknown on a 10 Mega hardware

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

TG0014 58 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

Display an IP Phone Board structure : 6


Display all IP Phone Board structure : 7
Display all Mac Address Used : 8
Display IP Phone by adr mac/adr adr ip/mcdu : 9
Display number of IP Phones connected : 10
Display all IP Phones connected on a board : 11
Display all IP Phones connected with boards : 12
Ip Phone download Menu : 13
INT IP Menu : 14
Domain Menu : 15
Status Menu : 16
Quit this tool : 0
Enter your choice : 8

ALL MAC ADDRESS USED


+----+--------------------+-+-----+--------+-----------+---------------+----+
|Indx| Mac Address | |Neqt | QMCDU | Name | Ip Address |Type|
+----+--------------------+-+-----+--------+-----------+---------------+----+
|0001|...........
|0022|00:80:9f:3b:ce:f7:00|-|00979|4139 | DUPONT A |000.000.000.000| V1 |
|0023|......
|0025|00:80:9f:3b:d2:df:00|-|00984|4152 | DUCHNE P |000.000.000.000| V1 |
|0026|......

Ed. 03 / 15 December 2008 59 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

7.5. IP Phone blocked in phase 5-6/6


Problem
IP Phone blocked in initialization phase, the sets loop in phase 5-6/6.
Symptoms
Following system or network problems, when all the IP Phones on a system restart, a certain
number of sets remain blocked in the initialization phase. The sets loop in phase 5-6/6, and the
connection with the system cannot be made.
Analysis and Explanation
This problem can be observed on sites with more than 30 IP Phones. Up to 60 % of the sets on
an installation can be in this situation, and only cutting off the power supply can resolve the
blocking situation.
The problem is often noted after loss of a signaling link; as the system does not distinguish
between partial and total startup of a set, the set looks during the wait for the "TSCP_INIT " UA
message.
The problem is identified as a system bug.
Solution
This problem is reported in the anomaly report CDHva58481, and the correction is supported in
the following system versions:
R3.2 C1.714.3ae
R4.1.1 D1.311.7.ac
R4.2.1 D2.304.4.v
Any info for R5.0 Lx?
R5.0 Ux D2.313.7.h
R5.0.1 Ux D2.314.4 Is it still an issue in R5.1?
R5.0 Lx ?

TG0014 60 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

7.6. Untimely IP Phone reset


Problem
Call cut off; untimely IP set reset.
Symptom
IP sets sometimes restart inopportunely, regardless of the Alcatel OmniPCX version. On certain
installations up to 50 resets per day are observed.
Untimely call cut-offs with the sets being reset may also be observed.
Analysis and Explanation
Problems have been observed with the INTIP board with INTIP edition 3BA 23193 ABAD 02
when configured at 100 Mbit/s. INTIP boards have been delivered with a defective Quartz
oscillator. The boards function correctly if the configuration is modified to 10 Mbit/s. At 100
Mbit/s on Ethernet installations these boards experience malfunctions that may generate IP set
losses (INTIPB) and degraded audio quality.
Solution
Consult technical communication TC0421 No initialization of the INTIP board when
configured at 100 Mbit/s.
Send the faulty INTIP board to Hardware Support with the following problem description:
"INTIP does not work at 100 Mbit/s due to defective oscillator Defective oscillator reference:
E25.000 or E25.000B/ 2PHxxxx or PHBxxx".
Example of incidents reported by the system
14/07/03 15:47:28
001001M|10/01/0/104|=2:0378=6,(1,22),00:80:9F:3B:EC:2D:00,91561
14/07/03 15:47:35
001001M|10/01/0/104|=2:0378=10,(1,17),00:80:9F:3B:EC:2D:00,91561
14/07/03 15:47:39
001001M|10/01/0/104|=2:0378=8,(1,17),00:80:9F:3B:EC:2D:00,91561

(101)XA001001> INCINFO GEA 378

INCIDENT NUMBER: 378


NETWORK INDICATOR: ALCATEL 4400
OBJECT CLASS: DHS3TERMINAL
EVENT TYPE: EQUIPMENTALARM (4)
PROBABLE CAUSE: EQUIPMENTMALFUNCTION (15)
SEVERITY: MAJOR
"P1"
"P1 : ERROR TYPE"
"P2 : CRYSTAL NUMBER OF THE SIGNALING BOARD (OPTIONAL)"
"P3 : BOARD NUMBER OF THE SIGNALING BOARD (OPTIONAL)"
"P4 : ETHERNET ADDRESS"
"P5 : SET NUMBER OF SET IF POSSIBLE"
"INCIDENT FORMAT : P1,(P2,P3),P4,P5"
"SIGNALING LINK PROBLEMS ON "
"LINK ESTABLISHMENT OR EXISTANT LINK SHUTDOWN"
"SEVERAL CAUSES "
"DEPEND OF THE ERROR VALUE P1:"
" 0 LIEN OUT OF ORDER - IP COUPLEUR IP NOT INITIALIZED"
" 1 LIEN OUT OF SERVICE - MAC ADDRESS ALREADY ALLOWED"
" 2 LIEN OUT OF SERVICE - IPV6 NOT SUPPORTED"

Ed. 03 / 15 December 2008 61 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

" 3 LINK OUT OF SERVICE - IP COUPLEUR LACK OF RESSOURCES"


" 4 LINK OUT OF SERVICE - NON EXISTANT LINK"
" 5 LIEN EN SERVICE - LINK ALREADY SET"
" 6 LINK OUT OF SERVICE - LINK DOWN"
" 7 LINK OUT OF SERVICE - IP COUPLEUR INTERNAL ERROR"
" 8 LIEN EN SERVICE - LINK ESTABLISHED"
" 9 LINK OUT OF SERVICE - NETWORK ERROR"
" 10 LINK OUT OF SERVICE - PEER NOT CONNECTED"
" 11 LINK OUT OF SERVICE - ON PEER DEMAND"
" 12 LINK OUT OF SERVICE - ON CPU DEMAND"
" 13 LINK OUT OF SERVICE - IP COUPLEUR INTERNAL ERROR"
" 14 LINK OUT OF SERVICE - IP COUPLEUR OUT OF SERVICE"
" 20 LINK ON ON A OUT OF SERVICE SET - IDLE STATE -"
" 21 LINK ON ON A OUT OF SERVICE SET - ACTIVE STATE -"
"NO REACTION OF THE SYSTEM."
"CHECK IP RESSOURCES BOARDS WITHIN IP PHONE"
"CHECK THE PHYSICAL CONNEXION PLUG"
"ON CAUSE 20 AND 21, ONLY NOTICE THE PROBLEM, AND GIVE"
"IT TO THE R&D SUPPORT. THIS IS A DEFENSE MECANISM WHICH "
"SHOULD BE ACTIF ONLY ON A VERY BAD IP NETWORK.";

TG0014 62 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

7.7. Poor sound quality on callback to busy set


Problem
An IP set has degraded sound quality following a callback request.
Symptom
An IP set at a remote site is busy on a call (64K link) and a set from the main site leaves it a
callback request; when the call is set up after the line is released, the voice quality is very
degraded.
Analysis and Explanation
This phenomenon is observed if the calls on a callback request between a remote site and a
main site use compression (G723 or G729); the system asks for the call to be set up without
compression: G711.
This problem is observed on IP Phones in single-line configuration; the problem is not
reproduced in a multi-line configuration.
Solution
The problem identified as an Alcatel OmniPCX bug is reported in the anomaly report
CDHva59786. The correction is available in versions:
D2.314.5
D2.304.4.w

Ed. 03 / 15 December 2008 63 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

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

Releases Versions V2 IP Phone binary version


R3.2M (phase out) C1.714.3.af 2.13
R4.1.1 D1.311.7.ac 2.13
R4.2 D2.304.4.s 2.11
R5.0 Ux D2.313.7.b 2.11
R5.0 Lx E1.604.9.e 2.11

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:

TG0014 64 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

This line of the trace indicates that


the binipph1 file is not available
on the TFTP server.

Ed. 03 / 15 December 2008 65 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

7.9. Degraded sound quality on IP Phone behind a WAN link


Problem
Users complain of degraded sound quality on their IP Phones.
Symptom
Users on IP Phone complain of poor sound quality in reception. The users complain of calls
where the voice is "metallic," "chopped" or with "brown-outs". The vast majority of calls are of an
acceptable quality; the sound problems observed are random. This phenomenon is observed on
IP sets located on a remote site connected by a WAN link to the Alcatel OmniPCX (see site
diagram below).
Analysis and Explanation
The remote site is connected to the headquarters through a dedicated E1 128 Kb/s type link,
where 96 Kb/s are reserved for voice transport. Prioritization of voice over the data exchange has
been established using the TOS field. Voice calls use G729 compression, and the header
compression is set in the routers.
The tests carried out allow degradation of the sound quality to be highlighted after setting up the
fourth call superposed on data traffic.
The traces and the statistic summaries in the routers have highlighted an imbalance in the
bandwidth consumed in the headquarters to the remote site and back.
Analysis has led to the following conclusions: the compression of the header is not configured in
the same way in the two routers that supervise the WAN link. The effective and measured
compression rates require limiting the number of G729 voice calls to three (3) for a reserved
bandwidth of 96 Kbits/s.
The CISCO C7206 router (located on the main site) has an average compression rate of 1.42.
The CISCO C2610 router (located on the remote site) has an average compression rate of 2.7.
Solution
To guarantee optimal sound quality, the number of calls must be limited to three (3) on a link of
the type described in this example.
A software update for the routers may be necessary in order to obtain a homogeneous and
optimized compression rate in both transmission directions. This update will allow maximum use
of the dedicated link bandwidth.
Investigations/traces
The following is a list of the commands that allow access to the CISCO router statistics.
Reading the statistics on the router at headquarters (headquarters link to remote site), it is seen
that two (2) G729 calls are set up between the headquarters and the remote site. The imbalance
between the two transmission directions is considerable (explained by the difference in
compression rates for the two routers):
Routeur_C7206>sho int multi 309
Multilink309 is up, line protocol is up
Hardware is multilink group interface
Internet address is 10.94.4.58/30
MTU 1500 bytes, BW 128 Kbit, DLY 100000 usec,
reliability 255/255, txload 109/255, rxload 51/255

TG0014 66 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

Encapsulation PPP, loopback not set


Keepalive set (10 sec)
DTR is pulsed for 2 seconds on reset
LCP Open, multilink Open
Open: IPCP
Last input 00:00:00, output never, output hang never
Last clearing of "show interface" counters 03:17:27
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queuing strategy: weighted fair
Output queue: 0/1000/64/0/3524 (size/max total/threshold/drops/interleaves)
Conversations 0/6/32 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
30 second input rate 26000 bits/sec, 70 packets/sec
30 second output rate 55000 bits/sec, 71 packets/sec
937167 packets input, 28124439 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
953973 packets output, 35415882 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
Reading the statistics on the router at headquarters (headquarters link to remote site), it can be
seen that one G729 call is set up between the headquarters and the remote site. This reading
confirms the imbalance between transmission and reception (and the difference in the
compression rate):
Routeur_C7206>sho int multi 309
Multilink309 is up, line protocol is up
Hardware is multilink group interface
Internet address is 10.94.4.58/30
MTU 1500 bytes, BW 128 Kbit, DLY 100000 usec,
reliability 255/255, txload 41/255, rxload 21/255
Encapsulation PPP, loopback not set
Keepalive set (10 sec)
DTR is pulsed for 2 seconds on reset
LCP Open, multilink Open
Open: IPCP
Last input 00:00:00, output never, output hang never
Last clearing of "show interface" counters 03:42:11
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0/4030 (size/max total/threshold/drops/interleaves)
Conversations 0/6/32 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
30 second input rate 11000 bits/sec, 42 packets/sec
30 second output rate 21000 bits/sec, 42 packets/sec
988830 packets input, 30154574 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
1005959 packets output, 38832773 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions

Routeur_C7206>sho policy-map int multi 309

Ed. 03 / 15 December 2008 67 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

Multilink309 output : QoS-site-distant


Weighted Fair Queueing
Class VoIP-RTP
Strict Priority
Output Queue: Conversation 40
Bandwidth 96 (kbps) Packets Matched 981919
(total drops/bytes drops) 0/0
Class class-default
Flow Based Fair Queueing
Maximum Number of Hashed Queues 32 Max Threshold 64 (packets)
(total queued/total drops/no-buffer drops) 0/0/0

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

TG0014 68 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

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

OmniPCX INTIPA Main site

CPU
RTC

CISCO C7206
router

CISCO C2610
router

Remote site
IP Phones

Ed. 03 / 15 December 2008 69 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

7.10. One-directional call in version V2.11


Problem
A call that requires involvement of an IP Phone becomes one-directional after a certain period of
time.
Symptom
On an Alcatel OmniPCX Enterprise 5.0 system in an unfavorable network environment (a
network with considerable jitter and delay, or with packet loss), one-directional calls are observed
on V2 IP Phones.
Analysis and Explanation
Through traces carried out using a network analyzer utility ("sniffer", e.g. Wireshark), it has been
noted that the faulty IP Phone continues to send RTP frames with a "silence" content, and present
the hexadecimal codes 0x55, 0x54, 0xAA.
Solution
Update the IP Phones version to at least version 2.13 or the latest version 2.18.
Caution: With version 2.13 in G711 and 20-millisecond framing, there is another problem
that leads to one-directional calls.
Extract of a trace for the problem
The IP Phone 130.67.128.237 sends RTP frames
containing silence: hexa code d5 to the IP set
130.67.128.232, the call is one-directional.

TG0014 70 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

7.11. One-directional call in version V2.13


Problem
A call that causes involvement of an IP Phone becomes one-directional after a certain time.
Symptom
A call involving an IP Phone becomes one-directional after a certain time, and the party no
longer hears the other person speaking on the IP Phone.
Analysis and Explanation
Network traces show that the IP Phone definitely stops sending UDP frames. The last frame sent
by the set is too short; the message sent is missing two bytes.
On the next call, everything returns to normal, the "start RTP" message reactivates both
transmission directions.
The problem is only in evidence when operating without compression in "G711" mode with 20-
millisecond framing.
Review/Modify: IP Phones Parameters

Node Number (reserved) : 1
Instance (reserved) : 1
Parameter + Default Voice Coding Algorithm

Default Voice Coding Algorithm + Without Compression


Review/Modify
Node Number (reserved) : 1
Instance (reserved) : 1
System Option + Framing VOIP

Framing VOIP + 20 ms

Solution
Two solutions exist:
Select 30-millisecond framing.
Update the IP Phone version to the version 2.18.

Ed. 03 / 15 December 2008 71 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

Extract of a trace for the problem

The IP Phone 192.168.22.53 stops sending, the last packet


sent is too short, the UDP frame is missing two bytes. After
this frame, the call becomes one-directional.

TG0014 72 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

7.12. "Network down" message: see CDHva55914


Problem
The IP Phone displays the "Network down" message.
Symptoms
After a network problem, the IP set in service may display the "Network down" message.
This problem can be observed during a call if only the signaling link is disturbed, the set may
display the message "Trying to connect" when the audio call is still active.
Analysis and Explanation
In a configuration with a minimum of two INTIPA boards, if an IP Phone loses its signaling link
with an INTIPA, the signaling channel is switched over to the second board. The IP Phone
displays the "Network down" message to indicate this momentary loss of signaling. The problem
is that the IP Phone does not update its display after switching over the signaling link to the
second board.
The IP Phone displays this message even after re-establishing the signaling link. This incorrect
information disturbs the end user, who considers their set to be out of service. If this message is
presented to the user, the user is tempted to spontaneously reset their set. Off-hooking and then
on-hooking the set updates the display (the system sends screen update messages).
This problem may appear during a call. The IP Phone momentarily loses the signaling channel,
the call channel remains set up (see IP set operating principle diagrams). The set displays the
message "Trying to connect" for the rest of the call, the message only disappears when the call is
on-hooked, when the system updates the display.
Solution
Version 2.18 of the IP Phone corrects the above problem. The point is recorded in anomaly
report CDHva55914.
To have this correction, the sites must be updated with an Alcatel OmniPCX version that includes
the V2.18 binary for the integrated IP Phone.
As indicated in this analysis, this problem is in evidence following network problems or
disturbances that need to be investigated in order to find solutions to these network failures.

Ed. 03 / 15 December 2008 73 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

7.13. No "proceed to select" tone


Problem
When it goes off-hook, the IP set does not give a "proceed to select" tone.
Symptom
With integrated IP sets 4010, 4022, and 4037, if a South American database is selected, the IP
sets no longer provide certain tones (proceed to select, for example). Instead, the user hears
silence.
Analysis and Explanation
The problem has been identified as a system bug present mainly in South American versions,
and in particular for Columbia, Venezuela and Costa Rica.
On initialization of the IP sets, tones are loaded into the set; integrated IP sets do not accept
negative level tones. The sets reject all negative level tones, and instead present silence in place
of the standard tones.
The tones loaded in the IP Phones can be traced and displayed as follows:
> tuner km
> mtracer -e
> (Del)
> tuner all=off +at cpu cpl +bbuf
> actdbg all=off cnx=on ipp=on
> trc init
> mtracer -u
..............
_________________________________ UA Message ______________________________

( (115906:013083) 89: Send_IO1 ( 7 )


( lg : 142 dest : 0 src : 15 cr : 0 cpl : 7 term : 254 type b4
( <<<< message send : TSC_IP_SEND (b4)
( Mac Address : 0:80:9f:3d:10:e4 Sub Address : 0
(__________________________________________________________________________
(
( OP:[13] IP DEVICE ROUTING (l=51) : DEF_TONE
( Tones entry Number : 4
( Tone pair 1 : F 0 236, V 169, F 1 8 , V 4
( Tone pair 2 : F 0 236, V 8, F 7 0 , V 0
( Tone pair 3 : F 0 236, V 120, F 5 0 , V 0
( Tone pair 4 : F 0 236, V 182, F 3 0 , V 0
( OP:[13] IP DEVICE ROUTING (l=62) : SET_PARAM_REQ
( SNMP_MIB2_SYSCONTACT (l=20) : Number not available
( SNMP_MIB2_SYSNAME (l=12) : 3100 - 3100
( SNMP_MIB2_SYSLOCATION (l=22) : A4400 Network 0 Node 1
( OP:[13] IP DEVICE ROUTING (l=5) : GET_PARAM_REQ
( Local Ip Address
( Netmask
( TSC_IP Firmware Version
(__________________________________________________________________________

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.

TG0014 74 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

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.

Ed. 03 / 15 December 2008 75 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

Correction
The second topic is a problem recorded in anomaly report XTSce35528, the correction is
available in the IP Phone 2.21 version.

TG0014 76 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 IP PHONES ISSUES

8. BEFORE CALLING ALCATELS SUPPORT CENTER


Before calling Alcatels Business Partner Support Center (ABPSC), make sure that you have read
through:
the Release Notes which lists features available, restrictions etc.
this chapter and completed the actions suggested for your systems problem.
Additionally, do the following and document the results so that the Alcatel Technical Support can
better assist you:
Have any information that you gathered while troubleshooting the issue to this point
available to provide to the TAC engineer (such as traces).
Have a data network diagram. Make sure that relevant information are listed such as
bandwidth of the links, equipments like firewalls, DHCP servers etc.
Provide a sniffer trace when relevant (in case of initialization problem, etc.).

Note
Dial-in or Telnet access is also desirable to help with effective problem resolution.

Ed. 03 / 15 December 2008 77 TG0014


OmniPCX 4400/Enterprise
IP PHONES ISSUES TROUBLESHOOTING GUIDE NO. 14

TG0014 78 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 APPENDIX 1
IP PHONES ISSUES STATUS OF THE IP LINK

STATUS OF THE IP LINK

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.

Equipment item 1 Equipment item 2 Real link status


1 Autonegotiation Autonegotiation 100FULL
2 100FULL Autonegotiation 100HALF
3 100HALF Autonegotiation 100HALF
4 10FULL Autonegotiation 10HALF
5 10HALF Autonegotiation 10HALF
6 100FULL 100FULL 100FULL
7 100FULL 100HALF 100HALF
8 100FULL 10FULL No link
9 100FULL 10HALF No link
10 100HALF 100HALF 100HALF
11 100HALF 10FULL No link
12 100HALF 10HALF No link
13 10FULL 10FULL 10FULL
14 10FULL 10HALF 10HALF
15 10HALF 10HALF 10HALF

Caution: The IP Phone may give an incorrect speed or mode indication (half-duplex/full duplex
mode) if an invalid configuration is selected.

Ed. 03 / 15 December 2008 1 TG0014


OmniPCX 4400/Enterprise
APPENDIX 1 TROUBLESHOOTING GUIDE NO. 14
STATUS OF THE IP LINK IP PHONES ISSUES

TG0014 2 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 APPENDIX 2
IP PHONES ISSUES ERROR CODES

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

Caution: the X.23 error may be detected at every step: X = 1,..., 6


Num Status Status string F/B E/ Description
W
1.00 NET_INIT Started S Start of Network initialization step (EIM
driver...)
1.01 NET_INIT Success S Network initialization successful
1.03 NET_INIT Fail E Network Initialization failed (driver, nucleus
error...)
1.04 NET_INIT No mac address B E No Ethernet mac address stored in flash
2.00 GET_ADDR Started S Address getting and/or checking step
started
2.10 GET_ADDR Bad static IP B E Terminal in static mode without IP address
Params
2.02 GET_ADDR Retry S Retry after error while getting IP
parameters in dynamic mode
2.01 GET_ADDR Success S Successful end of address getting/
checking step
2.03 GET_ADDR Fail F E Getting IP parameters failed
2.05 GET_ADDR No DHCP server W DHCP server is not responding in dynamic
mode.
2.06 GET_ADDR Bad local IP addr B E Local IP address is incorrect
2.07 GET_ADDR Bad router IP B E Router IP address is incorrect
addr
2.08 GET_ADDR Router not W Router not responding to ping
responding
2.09 GET_ADDR Bad TFTP IP addr B E TFTP server IP address is incorrect
2.21 GET_ADDR Unknown error B E Fatal error found while checking IP
parameters.
2.24 GET_ADDR IP addresses B E Address, mask and router do not match
mismatch together.
3.00 LOAD_CONFIG_FILE Started S Starting of step of loading configuration
file (lanpbx.cfg)

Ed. 03 / 15 December 2008 1 TG0014


OmniPCX 4400/Enterprise
APPENDIX 2 TROUBLESHOOTING GUIDE NO. 14
ERROR CODES IP PHONES ISSUES

Num Status Status string F/B E/ Description


W
3.01 LOAD_CONFIG_FILE Success S Successful end of loading config file step
3.02 LOAD_CONFIG_FILE Retry W Retry after error during config file loading
step
3.03 LOAD_CONFIG_FILE Fail E Loading of config file failed.
3.11 LOAD_CONFIG_FILE No response W TFTP server is not running
3.12 LOAD_CONFIG_FILE Remote error W Error on the server (file not found, no more
sockets...)
3.15 LOAD_CONFIG_FILE Bad file E Bad content of config file downloaded
3.21 LOAD_CONFIG_FILE Unknown_error E Unknown error while downloading config
file
4.00 LOAD_BINARY_FILE Started S Starting of step of loading binary file
(binipph1)
4.01 LOAD_BINARY_FILE Success S Successful end of loading binary file step
(loaded or not)
4.02 LOAD_BINARY_FILE Retry W Retry after error during binary file loading
step
4.03 LOAD_BINARY_FILE Fail E Loading of binary file failed.
4.11 LOAD_BINARY_FILE No response W TFTP server is not running to supply binary
file.
4.12 LOAD_BINARY_FILE Remote error W Error on the server (file not found...)
4.14 LOAD_BINARY_FILE File too large E Binary file is to large. It cannot be
downloaded
4.15 LOAD_BINARY_FILE Bad file E Error in downloaded binary file
(connection failure, ...)
4.16 LOAD_BINARY_FILE Header_error E Content of header of binary file is incorrect
(name, length)
4.17 LOAD_BINARY_FILE Same version W Version found in CPU is the same as the
current running
4.18 LOAD_BINARY_FILE New version W A new version is found in CPU. It will be
loading downloaded
5.00 LOAD_BINARY_FILE Started S Starting of step of flashing a new version
5.01 LOAD_BINARY_FILE Success S Successful end of version flashing step.
5.03 LOAD_BINARY_FILE Fail E Flashing of new version failed.
6.00 LOAD_START_FILE Started S Starting of step of loading start file
(starttscip)
6.01 LOAD_START_FILE Success S Successful end of loading start file step
6.02 LOAD_START_FILE Retry B W Retry after error during start file loading
step
6.03 LOAD_START_FILE Fail B E Loading of start file failed (loop or new
CPU)
6.11 LOAD_START_FILE No response W TFTP server is not running to supply start
file.
6.12 LOAD_START_FILE Remote error W Error on the server (start file not found...)
6.20 LOAD_START_FILE Try other cpu W Change to next CPU in list to download
binary and start file
0.22 END Dummy S Init and download is terminated (successful
or not)
X.23 all No eth link W Ethernet link seems to be not connected

TG0014 2 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 APPENDIX 3
IP PHONES ISSUES NETWORK TRACES

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.

Ed. 03 / 15 December 2008 1 TG0014


OmniPCX 4400/Enterprise
APPENDIX 3 TROUBLESHOOTING GUIDE NO. 14
NETWORK TRACES IP PHONES ISSUES

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).

TG0014 2 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 APPENDIX 4
IP PHONES ISSUES ADD-ON MODULE

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.

Ed. 03 / 15 December 2008 1 TG0014


OmniPCX 4400/Enterprise
APPENDIX 4 TROUBLESHOOTING GUIDE NO. 14
ADD-ON MODULE IP PHONES ISSUES

TG0014 2 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 APPENDIX 5
IP PHONE ISSUES Alcatel IP PHONE CISCO 3550 PWR
SWITCH CATALYST INTERWORKING
THROUGH THE "IN LINE POWER"
FUNCTION

Alcatel IP PHONE CISCO 3550 PWR


SWITCH CATALYST INTERWORKING
THROUGH THE "IN LINE POWER" FUNCTION

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.

Ed. 03 / 15 December 2008 1 TG0014


OmniPCX 4400/Enterprise
APPENDIX 5 TROUBLESHOOTING GUIDE NO. 14
Alcatel IP PHONE CISCO 3550 PWR IP PHONE ISSUES
SWITCH CATALYST INTERWORKING
THROUGH THE "IN LINE POWER"
FUNCTION

TEST ON THE POWER SUPPLY OF THE ALCATEL IP PHONE BY THE ETHERNET PORTS
OF THE CISCO 3550 PWR SWITCH

e-Reflexes Alcatel IP Phone

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

TG0014 2 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 APPENDIX 5
IP PHONE ISSUES Alcatel IP PHONE CISCO 3550 PWR
SWITCH CATALYST INTERWORKING
THROUGH THE "IN LINE POWER"
FUNCTION

CONNECTED TO THE IP NETWORK VIA THE ALCATEL IP PHONE


Several file transfer tests have been performed (first transfer test: 36 Mb file, second test: 117 Mb
file).
The subjective tests performed are conclusive; no voice degradation was noted.

Ed. 03 / 15 December 2008 3 TG0014


OmniPCX 4400/Enterprise
APPENDIX 5 TROUBLESHOOTING GUIDE NO. 14
Alcatel IP PHONE CISCO 3550 PWR IP PHONE ISSUES
SWITCH CATALYST INTERWORKING
THROUGH THE "IN LINE POWER"
FUNCTION

TG0014 4 Ed. 03 / 15 December 2008


OmniPCX 4400/Enterprise
TROUBLESHOOTING GUIDE NO. 14 APPENDIX 6
IP PHONES ISSUES BEHAVIOR OF THE IP PHONE IN THE
PRESENCE OF CONSIDERABLE MULTICAST
TRAFFIC

BEHAVIOR OF THE IP PHONE IN THE


PRESENCE OF CONSIDERABLE MULTICAST
TRAFFIC

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.

Ed. 03 / 15 December 2008 1 TG0014


OmniPCX 4400/Enterprise
APPENDIX 6 TROUBLESHOOTING GUIDE NO. 14
BEHAVIOR OF THE IP PHONE IN THE IP PHONES ISSUES
PRESENCE OF CONSIDERABLE MULTICAST
TRAFFIC

TG0014 2 Ed. 03 / 15 December 2008

Das könnte Ihnen auch gefallen