TG0028
TG0028
TG0028
02
This troubleshooting guide explains the operation of an IP Touch in a VoIP environment. Its aim is to
help diagnose and resolve problems in activating the IP Touch.
1
OmniPCX Enterprise
TROUBLESHOOTING GUIDE No. 28 IP TOUCH ISSUES
CONTENTS
1. INTRODUCTION ..........................................................................5
2. REFERENCES................................................................................5
3. HISTORY......................................................................................5
8. POWER CLASSIFICATION...........................................................37
8.1. IEEE Recommendation and IP Touch classification .................................. 37
8.2. Consumption Detail ................................................................................ 37
APPENDICES
APPENDIX 1 - STATUS OF THE IP LINK
1. INTRODUCTION
This troubleshooting guide explains the operation of an IP Touch in a VoIP environment. Its aim is
to help diagnose and resolve issues in activating the IP Touch.
For voice quality issues, please refer to the troubleshooting guide TG0002 VoIP audio quality
problems.
2. REFERENCES
Following documents, dealing with subjects around IP Issues, are also available on BPWS:
• Troubleshooting guides:
♦ TG0001: Echo in a VoIP environment
♦ TG0002: VoIP audio quality problems
♦ TG0014: IP Phones issues
♦ TG0015: INTIP issues
• Technical Communications:
♦ TC0458: IP Phones VoIP technical characteristics
♦ TC0600: Alcatel IP Phones sets using “Power Over Ethernet” supplied by Cisco 3560
♦ TC0601 : Automatic VLAN Assignment (AVA) – Implementation guide and restrictions
♦ TC0623 : 802.1P/Q Configuration guidelines for Alcatel IP Phones connected to a Cisco
Catalyst Switch.
♦ TC0633: The IP Touch sets do not restart from versions f1.602.3.m and f1.603.1.c
♦ TC0663: IP Touch does not restart after upgrading of new versions
3. HISTORY
Edition 01: Creation of the troubleshooting guide.
4.1. Abbreviations
• MMI : Man Machine Interface (Used in this document for IP Touch MMI)
4.2. Notations
The table below gives the “Signaling Link Board” from OmniPCX Enterprise R6.0.1 which will be
used, depending on the:
- Choice of a “Signal Link Board” which is in the same domain as the IP terminal.
- When there is no “Signal Link Board” in the IP set domain, “Signal Link Board” will be chosen
from default domain.
- When there is no “Signal Link Board” available, the “Signal Link Board” is searched in all the
domains
The following table shows the differences regarding the Signaling Ling Board connection between an IP Phone and an IP touch.
(1) The load is distributed according to a load repartition optimization between the different available couplers.
(2) Terminals are connected to GD board, when the founded other coupler in the domain are busy
(3) These couplers can only accept Signaling link for IPP and for IPT in the case “IP -> IP Parameters -> IP Phone signaling
on eMGD = YES”
(4) In the case of backup, the GD (/GA) boards in rescuer mode accept without conditions the IP terminals in their domains
(5) When there are no other board available, the terminal in domain X will be connected to the IpLink
Remark: Historically, parameter “System -> Other System Parameters -> System parameters -> IPTouch IP on a real INTIPA
board= NO” has been created in the way that IP Touch terminals have the same behavior than IP Phone terminals regarding
to the “Signaling Board”. Today this parameter should only be modified with R&D agreement, and has by default to be set to
NO.
6. OPERATING PRINCIPLES
6.1. Overview
In an Alcatel OmniPCX Enterprise context, an IP Touch should be able to set up its 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, a signaling channel is set up to a “Signaling link Board”
• During a call, the signaling transits through the signaling channel set up with the “Signaling
link Board” and the RTP flow transits through an additional channel. This can be set up
directly with another IP Touch (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, an IP Touch 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 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 Touch 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 Touch adapts the
speed and the transmission mode to the configuration of the equipment with which it will
interconnect: switch, hub, etc.)
• The IP Touch is able to manage 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. Since IP Touch version 2.18 and Alcatel
OmniPCX Enterprise R5.1, the VLAN number assignment can be dynamic using the "AVA"
feature. From IP Touch version 1.55, it appears a “strict VLAN” checkbox. If this box is
checked, the terminal accepts only frames tagged with the right VLAN ID (obtained through
AVA or assigned via the LOCAL MMI). If the strict VLAN is disabled, the terminal accepts
all frames (tagged and untagged). (See also FAQ and Technical Communication
TC0633)
The binary is downloaded using a TFTP READ request sent to the maincpu
address. If the binary file cannot be downloaded after all TFTP retries, the terminal
continues with step 5.
- (3) flash the new downloaded binary.
After a checksum test on the downloaded binary, the file is flashed. It replaces the
not–current of the two binary versions managed by the terminal. A new checksum
test on the flashed binary is performed. If successful, the binary is marked as valid
and the terminal resets If a problem occurs during the flashing step (bad checksum,
flashing error, etc), the terminal continues with step 5, and the user is notified with
the error
o Fast-Init: After step (2), if a maincpu address is found, steps 3 & 4 are skipped and
the terminal goes directly to step 5 (second run). If the download of the startnoe file
fails, the maincpu address is erased and the terminal is restarted in slow–init mode.
o Slow-Init After step (2), if a maincpu address is not found (not flashed), steps 3 &
4 are performed as described before.
Consult annex 2: “ERROR MESSAGES IN STARTING PHASE” indicating errors that can be
detected during the starting phase.
After that, a specific configuration display will appear, and the operator has the possibility to set
following parameters :
IP Mode :
- Static mode (IP address; a sub-network mask; the router address; TFTP 1,2,3 server;
TFTP Port; CPU 1 , CPU2 ) , or
- Dynamic mode,
VLAN :
Ethernet Links :
To save the changed parameters in flash you have to press the “running boy icon” on the upper
right corner of the screen.
7.2.1. Principle
The DHCP, Dynamic Host Configuration Protocol is used during step 2 of the starting phase to
acquire IP parameters from a DHCP server, if dynamic mode has been selected by the user.
This step is short-circuited if the IP Touch is configured with a static address.
As a DHCP client, the terminal conforms to RFC2131 and implements all mandatory items defined
in this RFC. In addition, the following non–exhaustive list of points are highlighted:
- required parameters are: subnet mask, router option, broadcast address, vendor specific
info, server id, renewal time, rebinding time and vendor class id (defined in RFC2132)
- defined string for “Vendor Class Identifier” option is for the IP Touch terminal: “alcatel.noe.0”.
- terminal doesn’t use “maximum DHCP message size” option (57) and does not use or
support extension of option field into “file“ and “name” options.
- after reset, the terminal starts a complete new DHCP procedure. It doesn’t try to ask for the
former IP address or try to look for it in preference.
- defined server strings for “Vendor Specific Information” option (43) field are:
- for INT/IP : “alcatel.int–ip.0”
- for A4400 : “alcatel.a4400.0”
- for A4200 : “alcatel.a4200.0”
The terminal checks these optional fields to give priority to Alcatel DHCP servers
7.2.2.1. Overview
Example:
DHCP exchange
DHCP Action
The DHCP server designated to process this request replies with the IP address of the IP Touch
and the address of the next server (call server address).
Before broadcasting its DHCPREQUEST, the terminal must select one of the DHCPOFFER
received according to the DHCP mode selected by the user using the “supervisor mode”:
– any–DHCP :DHCPOFFER from Alcatel DHCP servers are preferred (Vendor Specific Option). If
there are no DHCPOFFER from Alcatel servers, all DHCPOFFER are examined
If 2, 3 or 4 DHCPOFFER are possible candidate, the one with highest lease time is validated
If there are 2, 3 or 4 validated DHCPOFFER, the first one received is selected and a
DHCPREQUEST is sent (broadcast)
When the DHCPACK message is received, the DHCP procedure is complete. The terminal starts 3
timers (T1, T2 and T3) to handle renewing of the leased address (timer values are suggested from
the RFC):In both RENEWING and REBINDING states, if the Terminal receives no response to its
DHCPREQUEST message, it waits one–half of the remaining time until T2 (in RENEWING state)
and one–half of the remaining lease time T3 (in REBINDING state), down to a minimum of 60
seconds, before retransmitting the DHCPREQUEST message. This means that the last
DHCPREQUEST message is sent at least 60s before reset of terminal. (no DHCPREQUEST sent
inside the last minute)
7.2.2.6. Releasing
If the terminal decides to reset for any other reason than a lease expiration, it will send a
DHCPRELEASE message (unicast) to the server.
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.
Step 1 The IP Touch sends a DHCP request (message type DHCP DISCOVER) with a request
for a VLAN identity. The request is sent to the default VLAN. This request is sent without
an 802.1q tag.
Step 2 The DHCP server replies with a DHCP reply (message type DHCP OFFER) with a
VLAN number identifier.
Step 3 The IP Touch switches to 802.1q tag mode with the VLAN number received previously.
Step 4 The IP Touch 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 Touch and the address of the next server (call server address), and normal DHCP
exchanges, DHCP REQUEST, and DHCP ACK will continue
For more details, please consult Technical Communication TC0601 Automatic VLAN Assignment
(AVA) – Implementation guide and restrictions, or the Technical documentation under DHCP
module.
TFTP is used during steps 3, 4 and 5 of the starting phase. TFTP implementation is compatible
with RFC1350 (TFTP version 2) and with RFC2347 (TFTP Option Extension).
Exemple:
TFTP exchange:
When the IP Touch 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 after the TFTP process started.
The lanpbx.cfg can also be automatically generated thanks to “lanpbxbuild” command
The configuration file format is the following:
Description
TYPE : possible values are ‘A4400’ or ‘A4200’.
IP_DOWNLOAD : this is the IP address of the TFTP server to be used in step 4 (software
download) and step 5 (start file download)
PORT_DOWNLOAD : this is an optional field which represent an alternate port to be used for
any TFTP transfers (the default TFTP port is 69)
The IP Touch download will not be possible if the lanpbx.cfg file does not exist or is
incorrect. It will not be possible to access to the IP Touch debug mode by telnet.
from release 2.xx.xx bin4028, bin4038, and bin4068 are linked to 1 binary
file named: bin40x8
The start file step consists in downloading and analyzing the startnoe file.
The start file provides the UDP port number the terminal must open before receiving UA3G and
IP Touch messages using the UA over UDP transport protocol. The start file format is the following:
UDP_PORT_SIG = x
Description
UDP_PORT_SIG : the UDP port number to open (value must be between 0 and 65535)
7.4.1. Overview
After TFTP exchange, the “Signal Link Board” takes always initiative for connection establishment.
The link is established only when both sides of the connection have sent a CONNECT message
and received a CONNECT ACKNOWLEDGE message. Both sides have to wait the end of this
exchange before sending data.
Example
7.4.2. Details
Both Call Server and IP Touch Phone can take initiative for disconnection. The connection is
considered
as closed once the RELEASE_ACK has been received.
7.4.3. Follows-up
Before the Keep alive mechanism, there are some other messages which are exchanged between
OXE and IP Touch, which are not necessarily detailed in this troubleshooting Guide. Refer also to
section 7.4.5 .
7.4.4.1. Mechanism
KEEPALIVE is emitted regularly (using UDP_KEEPALIVE timer) when there is no traffic in order
to detect a network link–down failure. “Signaling link Board” takes initiative for KEEPALIVE packet
exchange.
IP Touch has only to acknowledge with a KEEPALIVE_ACK.
A connection is considered as lost if no packet has been received after UDP_LOST timer
expiration.
This timer is started each time a packet is received. The expiration of this timer means that no
KEEPALIVE has been received because the network link is down between “Signaling link Board”
and IP Touch Phone.
Once network failure has been detected, UDP_LOST_REINIT timer is launched. Then IP
terminal waits for a new signaling link to be established by system. If no connection request has
been received after UDP_LOST_REINIT timer expiration, IP terminal will reset immediately.
The system can disable the keepalive mechanism. In that case no keepalive message will be
exchanged.
This is configured by setting the following parameter
IP -> IP Quality of service COS -> UDP Keep-Alive to 0
In this case, IP terminals will be unable to detect a network failure if there is no activity on
“Signaling Link Board”. Moreover, if a new binary is present on the Call Server, the IP
Touch will not automatically download that new binary.
Either DATA packet emitted by OXE or IP terminals contains a sequence number that is used to
acknowledge the packet.
If no ACK is received, the DATA packet is re–emitted after 200 ms (first occurrence), then with a
periodicity of 1 second. The connection is considered as released after UDP_LOST timer
expiration. Then, either a new connection is established by system or IP–terminal reset after
UDP_LOST_REINIT timer expiration.
ACK packet is a DATA packet without data (only sequence numbers are significant). ACK packet
must not be acknowledged.
The protocol also supports acknowledge by DATA packet. An acknowledgement of the last
received DATA packet (expected sequence number) may be integrated in current DATA packet.
“Signaling Link Board” has a window to anticipate DATA packet transmission (several packets may
be sent before the acknowledgement receipt).
IP terminal has no window but it has to test the sequence number of incoming packets in order to
send a NACK on receipt of a DATA packet with a bad sequence number. The NACK packet then
contains the expected DATA packet sequence number. All received DATA packets with a wrong
sequence number are discarded and no more NACK packet must be sent by IP Touch Phone.
On reception of a NACK packet, DHS re–sends all DATA packets since negative
acknowledgement sequence number.
8. POWER CLASSIFICATION
The IP Touch Power Classification corresponds to Class 2 meaning a range between 3,84 and
6,49.
- Check the presence and configuration of the lanpbx.cfg file at OXE level
- Check the coherency of the VLAN configuration (terminal VLAN Number) in the network
- Check the IP configuration (router address, TFTP address, etc…) ; the precise cause is
displayed on the screen of the IP Touch
- Check that there are no IP duplicated address ; in that case a message “duplicate IP” can
be recorded in the IP Touch accessible through the command “defence” (see Annex 4 and
5)
- Check the IP connectivity in the data network by using commands like ping, traceroute …
(see Annex 4) ; check the configuration of the “default gateway” on the IP Touch
- Check the DHCP server accessibility ; when there are several DHCP servers for example, it
might be a wrong DHCP server which answers ; or for example, the DHCP server might in
a VLAN which is not accessible by the IP Touch
- Check the cause of reset of the IP Touch with the embedded command “defence” (see
Annex 4)
- Run a sniffer trace (see Annex 6) and check the initialization steps with the description
made in the section 7
- Check that there are no IP duplicated address (for example, an other set starts with the
same IP address ) ; in that case a message “duplicate IP” can be recorded in the IP Touch
accessible through the command “defence” (see Annex 4 and 5)
- If the cause is “UAUDP_LOST_CONNECT”, the signaling link with the Call Server has
been lost due to loss of UA Keepalive messages :
- Check that the “RTP direct” configuration at OXE level is consistency over the whole IP-
PBX network
- Check the data connectivity which might be ok in one direction but not in the other
direction ; for example routing issue or UDP filtering by a firewall in one direction
- In the OXE QoS Tickets (ipview commands), check the number of packets sent/received
- Make a sniffer trace with Ethereal and check the RTP packets, their size, whether are sent
in both directions to localize the issue
- Check the gain configuration in the OXE, normally default values should be used except for
specific situations :
at INTIP/GD gateway level, parameter IP->IP Phone parameters-> Volume in db for
IP-Phones
at IP Touch level, parameter Alcatel 8&9 Series-> Alcatel 8&9 Set Audio Parameters
-> Sending Audio Paths-> Analog Send Gain and Digital Send Gain
- Check the jitter and packet loss on the data network, which could explain lower audio level
because of packet interpolations
- Erase the MAC address in mgr -> user and perform a new registration
- If case of a network of several IP-PBXs, check the lanpbx.cfg configuration (must contain
CS IP address of all the nodes )
10.1. VLAN
Question:
I manage a VLAN “x” on my IP Touch via the MMI and a VLAN “y” on the system using
mgr: Does the terminal tag its frame with VLAN “x” during its download phase, and then
switch to VLAN “y” after the connect ?
Answer:
For the terminal
Each frame sent will be tagged from terminal with its one VLAN id “x” from the beginning of
the negotiations, meaning first IP exchanges
To summarize:
With VLAN management on the terminal: It is the VLAN id from the terminal + the Priority
managed in the OXE which are used (Immediate tagging)
Question:
Concerning strict VLAN
When in the IP Terminal I set:
- use VLAN : yes
- VLAN id : “x”
- Strict VLAN : “no”
Does the terminal accept frames with VLAN x, VLAN 0, and non tagged Frames ?
Answer:
Yes
Be careful VLAN 0 doesn’t exist, it’s an information which indicates the use of the default
VLAN (which will be different from 0)
And the terminal will send tagged “x” Frames.
Question:
Using the MMI of the terminal, I set
- Use VLAN : yes
- VLAN id : “x”
- Strict VLAN : yes
Does the terminal accept only tagged frame “x” ?
Answer:
Yes, with “x” <> 0
If “x” = 0, IP Touch accepts non tagged frames from IP Touch release 1.55.03
Question:
Why in some cases, when Strict VLAN is set on the terminal, IP touch stops on phase 5/5?
Answer:
This behavior is corrected in IP Touch release 1.55.03
For release 1.55.01 and 1.55.02, the terminal stays blocked (See below)
Question:
Using to the MMI of the terminal, I set
Use VLAN : no
Strict VLAN : yes
What kind of frame will be accepted from the terminal, because no VLAN id has been
specified
Answer:
From IP Touch version 1.55.03, only non tagged frames. (Admitting that System will send
always VLAN=0 in the connect)
The handshaking for the connect should follow the next mechanism:
System -> Ip Touch connect
Ip Touch -> System connect Ack
Ip Touch -> System connect
System -> Ip Touch connect Ack
In the case where for example, the packets from the IP Touch are tagged thanks to a
802.1q use on the system. (meaning that the IP Touch packet will be tagged after connect)
with some Switch, like Cisco 3560, authorization must be given on the switch to let fill the
tagged packet with VLAN 0. On the other side following issue can happen, where IP Touch
waits despairing of system connect Ack, and then Reset
To resolve this issue, switch must accept tagged packet in VLAN 0. This can be
programmed on 3560 Cisco Switch using command
(For this switch Voice VLAN is supported only on access ports and not on trunk ports.)
Question:
How can I get Power Over Ethernet or IP Touch Class on POE Cisco switch
Answer:
Question:
Why, according to this document, my IP Touch is in Class 3
Answer:
This is depending on the serial number of your IP Touch. Around may 2004, IP Touch
classes evolved from Class 3 to Class 2. Serial number (or hard) can be found using the IP
Touch telnet and with command #id
#id#
soft 1.29.03
boot 1.00.10
hard 3GV23014ACCA040416
range IP
type C
linkdate Mon Oct 11 17:33:59 MEST 2004.
Question:
Power Over Ethernet doesn’t work on my PoE Switch
Answer:
Your Ethernet Interface is perhaps not configured to accept inline power:
(case of cisco switch)
Switch#configure terminal
Switch(config)#interface fastEthernet 0/1
Switch(config-if)#power inline ?
auto Automatically detect and power inline devices
never Never apply inline power
10.3. VAD
Question:
On an IP Touch (or e-Reflexe), I can observe during silence phase (nobody speaks) an
audio level attenuation, as if the distant user had been lost.
Answer:
When G711 codec is used, this is probably due to the activation of VAD. Deactivate the
VAD, and check if this behavior is still present.
Question:
How can I see some information, and can control (example reset) my IP Touch from the
OXE
Answer:
termstat d <directory number>
Question:
An e-reflexe IP Phone has been replaced with and IP Touch, and now we observe that this
new terminal doesn’t start correctly, and stops on “No Ethernet Link” message.
Answer:
A possible explanation can be due to the Jack/Plug contact difference between IP Touch
and e-reflexe. In fact when we insert the plug with a lateral push, then Ethernet link is not
present on the IP Touch, but works on the e-reflexe. This is due to the fact that the jack
connector pin on e-reflexes is build with a cylindrical section. The cylindrical section won’t
stripe the plastic guide as the square section in the IP Touch phone
Question:
The display of my IP Touch is blank although it seams that I can use it. I receive calls, and
can make calls.
Following incident is generated on the console:
Answer:
In some cases, a migration from an old Call Server version to a new version example R3 to
R6, as the database parameters are kept, MTU parameters can be different to 1024.
In this case, the message “IP_LINK Incident” indicates a wrong length of the message sent to
terminal, and this message will then be ignored.
Information
Below we show the status concerning the PC Ethernet link behind an IP touch terminal.
From release 1.56.01 and 2.54.03 the software will managed the PC Ethernet link with the
following rules:
no break of PC Ethernet
Signaling link lost with Call Server break of PC Ethernet link link
Question:
My IP Touch stays in “connect” phase.
Answer:
By default, the maximum delay between Step 1 and Step 4 are programmed in the system
tempo 271 to value 10, corresponding to 10x100ms = 1 second
In the case the Call handling doesn’t receive any answer before the end of this timer, it will
send a message to “IP Link board” to indicate that the terminal is not reachable, and the
mechanism restarts.
This timer 271 parameter can be increased in case of long delays on the data network.
Question:
My IP Touch refuses to be upgraded with a new binary version.
Answer:
There are some IP Touch version migration which are not allowed.
≥ 1.17.01
OK OK OK NOK
< 1.28.00
≥ 1.28.00
NOK OK NOK OK
< 2.00.00
≥ 2.00.00
OK OK OK NOK
< 2.03.00
My 4038 IP Touch has version 1.17.01, and the binary: bin4038 on OXE has version
2.13.00. In this case this version will not been download in one time. I have at first to
download an intermediate version, for our example we will choice intermediate version
1.55.03, and after that we can then upgrade, following above table, to version 2.13.00
Consult the Technical Communication TC 0663 dealing with “IP Touch sets do not
restart after upgrade to new versions”
10.10.Jitter size
Question:
What is the maximum size of the jitter buffer?
Answer:
High levels of jitter are not acceptable for applications running in real time. This results in
signal distortion, requiring the introduction of additional delays necessary for packet re-
assembly.
IP Touch uses a Dynamic buffer of 12 packets maximum.
10.11.NAT translation
Question:
Is it possible to connect the IP Touch through an IP NAT (Network Address Translation)
Device ?
Answer:
No, the UA protocol being not compatible with NAT because of IP addresses embedded in
the UA protocol which can thus not be translated by a NAT device .
A solution to avoid NAT translation in that case might be the use of a VPN tunnel.
10.12.Spatial redundancy
Question:
From which IP Touch version spatial redundancy is supported ?
Answer:
Spatial redundancy is supported by the IP Touch version 2.xx from OXE version 6.1.
10.13.Keep-alive mechanism
Question:
Is it possible to de-activate the Keep-alive mechanism ?
Answer:
The system can disable the keepalive mechanism. In that case no keepalive messages
will be exchanged.
See also section (7.4.4)
This is configured by setting the following parameter
IP -> IP Quality of service COS -> UDP Keep-Alive to 0
In this case, the IP Touch will not be able to detect a network failure if there is no activity on
the “Signaling Link Board”. Moreover, if a new binary is present on the Call Server, the IP
Touch will not automatically download that new binary.
Question:
What is the maximum delay accepted ?
Answer:
When you design networks that transport voice over packet, frame, or cell infrastructures,
it is important to understand and account for the delay components in the network. If you
account correctly for all potential delays, it ensures that overall network performance is
acceptable. Overall voice quality is a function of many factors that include the
compression algorithm, errors and frame loss, echo cancellation, and delay
The International Telecommunication Union (ITU) considers network delay for voice
applications in Recommendation G.114. This recommendation defines three bands of
one-way delay as shown in next table
10.15. SNMP
Question:
Does the IP Touch support SNMP (Simple Network Management Protocol) protocol ?
Answer:
In contrary to the e-Reflexes, the current versions of IP Touch don’t support SNMP.
Question:
What’s the duration of restart of an IP Touch after switching to the back-up signaling link
Answer:
The backup signaling link is used to recreate a signaling link to a Media Gateway if an IP
link goes down. This backup signaling link is set up via the public network with a back-up
Media Gateway.
When the Call Server observes the interruption of a "keep alive" dialog with a Media
Gateway, it waits for a certain time (specified in management). When this time has
elapsed, it declares the nominal link failed and initiates the backup link activation
procedure.
The internal modem of the rescuer Media Gateway calls the isolated Media
Gateway at the number defined in management.
o On the Rescued Media Gateway side:
The isolated Media Gateway, having observed the failure of the nominal link,
performs a reset. All calls in progress are then lost.
When the IP link is re-established, the transition is transparent for the IP Touch.
Question:
In some cases, during switch-over from the main Call Server to the back-up Call Server,
my IP Touch resets.
Answer:
During this switching, keepalive mechanism can be more longer then normal, so in some
case IP set will not receive keepalive signal, to resolve this issue, terminal’s UDP Lost
value can be increased.
Question:
What happens for the IP Touch in case of IP network break down between main and
standby Call Server ?
Answer:
When the contact between main and standby Call Server is lost, there is normally no
direct impact for the IP Touch as long as they continue to dialog with one of the Call
Servers. But their signaling board might change and switch to the former standby Call
Server.
When the IP network is back, the Call Server which will be considered as pseudo-main
Call Server (because for example he was not attached to the reference Media Gateway in
contrary to the other Call Server) will reset to become the standby Call Server and all sets
having their signaling link established with that Call Server will reset.
Question:
What happens when the IP Touch looses his signaling board ? Does the set reset ?
Answer:
If there is another signaling board available (see Section 5 Signaling Link Board for the
signaling board search), the signaling will be taken over transparently for the user by a new
board without reset of the IP Touch.
For the current communication of the set, there is no impact unless that communication
involves a compressor located on the board which is lost.
Before calling Alcatel’s Business Partner Support Center (ABPSC), make sure that you have read
through:
• the Release Notes which lists features available, restrictions etc.
• the Problem Report base available on the BPWS under section eSupport
• this chapter and completed the actions suggested for your system’s 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.
The table below gives the real link state depending on the devices parameters (invalid parameters
setting are shown darker):
Conclusion:
To avoid conflicts between both devices, following Simple Rule should be applied each time.
- When both devices are in Auto Negotiation, there is no problem, and 100 Mbps / Full
Duplex is automatically chosen
- When Both devices are set Manually, Same configuration Must be applied.
1. FAILURE SIGNALING
Failure signaling provides the user an indication (a message displayed on the screen) of what is
going wrong on the terminal (most of the time, this is a network problem). Messages displayed
are in English language.
After UDP_LOST timeout without receiving any message from the call server, the terminal
indicates to end user that the signalization link is broken and gives the reason of the failure:
if there is a cable problem between the terminal and the LAN switch, the following message is
displayed (A/B/C/D terminals):
”no Ethernet link”
If there is no problem between the terminal and the LAN switch, the problem could be anywhere
else on the network (cable problem between the LAN switch and the call server, the call server
goes down, etc) the following message is displayed (A/B/C/D terminals):
”connection lost”
Then, the terminal waits for a CONNECT message. After UDP_LOST_REINIT timeout, the
terminal indicates that it will reset by displaying the following message:
”reset...please wait”
This last message is also displayed if a reset request (UA3G or NOE message) from the call
server is received by the terminal.
If a duplicate IP address detected (terminal X receives an ARP request and finds that the source
IP address inside that packet is its own IP address), the following message is displayed during
five seconds (A/B/C/D terminals):
“duplicate IP address”
2. ERROR MESSAGES
The following table indicates the messages and errors displayed during the starting phase
(messages and errors are always displayed in English language)
short text: a short text is displayed on the screen (20 characters max on A terminal),only in
case of real error and not for progress indication (END, STARTED and SUCCESS)
ADD-ON MODULE
AOM-10 AOM-40
An Add On Module (AOM) is an extension keyboard for the B/C/D terminals. It provides 10 keys
(AOM–10) or 40 keys (AOM–40) associated to icons.
AOMs cascading is allowed only with 40 keys: an AOM–10 can only be the last element of an
AOM–40 chain.
AOMs and terminal are interconnected with an UART interface via a RJ45 connector.
With one terminal, up to 120 additional keys are possible (3 AOM–40) and up to 3 AOMs can be
cascaded (2 AOM–40+ 1 AOM–10 or 3 AOM–40)
Connection and Detection
How AOMs must be connected to a terminal ?
• power off the terminal
• connect the AOMs with RJ45 (first AOM to the terminal, second AOM to first the AOM, etc.)
• power on the terminal
AOMs must not be plugged to the phone while t h e phone is powered on. Even if the
previous mandatory recommendation is not respected, “hot plugging” of an AOM is not
destructive for the hardware (terminal and AOM).
AOM is detected during terminal initialization. If no AOM is detected, the UART used by AOM is
initialized for trace mode (115200 bits/s).
AOM–EL
AOM–EL stands for ELectronic Add On Module. AOM–EL is available on B/C/D terminals.
1. FOREWORD
This annex gives the different commands which can be run directly on IP Touch for diagnostic
help. Not all available commands will be given here, only the most useful will be given in this
annex. Don’t forget that you can use help command for each IP Touch command to discover the
parameters of each command like:
audio help
#audio#
audio [state|channel]
This command is run on OXE to authorize telnet access on IP Touch. In fact, by default telnet
server is disabled on IP Touch. The telnet execution on an IP Touch, in comparison to IP Phone,
can be run from any network element.
ippstat
>IPP (IP Phone) information :
>-------------------------------------
>Display the IP Address of the local node :1
>……………….
>Ip Phone download Menu : 13
>Timeout for telnet session of NOE set : 14
>INT IP Menu : 15
>Domain Menu : 16
>IPlink Menu : 17
>Status Menu : 18
>Quit this tool :0
3. COMMANDS ON IP TOUCH
3.1. Help
The ’Id’ function allows to get information about software version, hardware version,...
NoePhone > id
#id#
soft 1.29.03
boot 1.00.10
hard 3GV23014ACCA040416
range IP
type C
linkdate Mon Oct 11 17:33:59 MEST 2004
id OK
NoePhone >
3.3. IP configuration
The ’ipconfig’ function allows to get IP parameters. All flashed value will be taken into account after
reset.
The ’dwl’ function allows to get or set the binary name and tftp server information and starts a
binary download. The ’start’ describer forces the set to download and use after reset the binary
present on the server.
function definition :
dwl [ binary | server | port | go | { set { binary | server | port} <value> } ]
Restriction
“dwl go” is not available on NOE IP D with 8Mb SDRAM and one binary (containing data and code)
In some case, “dwl go” can generate a reset of the phone. To avoid such problem, do not use this
command when applications that needs a great amount of memory runs on the set. Also, if a set is
downloaded during a voice communication, this can disturb the audio quality.
The ’dwlmethod’ function allows to get or set the binary download method.
function definition :
dwlmethod [set no_binary|full]
The terminal contains 2 versions. the ’verswitch’ function allows rebooting on the other version
at the next reset of terminal
after verswitch
#verswitch#
verswitch OK
NoePhone >binary
#binary#
binary appbin0_r2
address bfc10000
internal name bin40x8_Rx______
length 1729491
version 2.12.00
main version 2.12.00
date 15:17-12/01/2005
binary appbin1_r2 SELECTED
address bf810000
internal name binnoeip_appl000
length 1617036
version 1.55.02
main version
date 19:29-11/01/2005
binary OK
The ’phy’ function allows to get the actual link properties and to set these link properties. When
the set option is used, the configuration of the link is changed immediately, but those parameters
are not stored in flash, so after a reset, the previous values of the link are used.
3.10. Defence/Reset
The ’defence’ function allows to get the number of defence flashed or the defence list and allows
to reset the defence list.
The cause of the IP Touch reset can be viewed thanks to this command.
The erase command flushes all the content of the defence sectors in the flash, then stores one
defence record with the version and the reset date of the running software.
3.11. Audio
The ’audio’ function allows to get audio mode information and number of active channels.
Remark: The parameter after the function name corresponds to the audio channel.
- Normal audio = channel 0
- Announcement Audio = Channel 1
Only channel 0 can be used for the moment
Remark:
**compressor possible values are :
– g711_a
– g711_mu
– g723_5.3kb/s
– g723_6.3kb/s
– g729
– ... (wide band codec tbd)
The ’rtp’ function allows to get rtp state and local or remote ip address and port
Remark: The parameter after the function name corresponds to the audio channel.
- Normal audio = channel 0
- Announcement Audio = Channel 1
Only channel 0 can be used for the moment
rtp 0
#rtp#
state active
direction rxtx
locip 172.25.32.55
locport 32514
remip 172.25.33.18
remport 32592
rtp OK
The ’rtcpstats’ function allows to get RTCP information during a voice communication.
The return value are standard ping results and are available on serial link only.
The ’voipstats’ function allows to see the Qos statistics of the 20 last calls (for release 1,1 or
more, only 10 in release 1.0). To take into account a communication, it has to be more than 20
seconds. Those statistics are not updated during a call but at the end of the call.
The cause of the reset of an IP Touch can be obtained via the embedded command “defence ”
(see Annex 4).
HARDWARE_RESET Occurs when the power cable of the set has been
unplugged or in case of power feeding loss
NOEP_RESET_MESSAGE The NOE reset message has been received from the
Call Server ; a fast init (without binary download) will
be performed
UA3G_TSC_RESET_MESSAGE The TSC reset message has been received from the
Call Server
NOEP_DOWNLOAD_REQUEST The NOE reset message has been received from the
Call Server ; a slow init (with binary download) will
be performed
UAUDP_LOST_CONNECT The UA/UDP signaling link with the Call Server has
been lost, because of failure of the keepalive
mechanism
Hereafter, an example of result of the command “defence 99” which shows two cases of reset.
The cause of reset is also reported in the system incident 426 at OXE level.
Example:
03/03/05 23:05:50 000001M|00/00/0/000|=4:0426=NOE terminal reset
13,(0,0),00:80:9f:56:74:b8:00,
ETHEREAL TRACES
Normally an Ethereal trace is done behind a Hub (or tap) to capture all the traffic from OXE to the
IP Touch, or thanks to mirroring on the Switch.
With the IP Touch, there is a third solution using the mirroring feature of the internal IP Touch
Switch
Trace with a Hub Trace with Switch Mirroring Trace with IP Touch Mirroring
After authorization of IP Touch telnet function, the ’mirror’ function allows to get the actual ports
mirroring state and to set the mirroring state on these ports (copy port traffic towards PC port).
(available in release 2 or more)
The switch behavior will be such that the frames are mirrored with the tag unchanged.
The PC port is still participating in the bridging while the mirroring feature is set. Some traffic
received on PC port will be received twice and may need to be filtered in the application on the
PC/probe sets on that port for trace. This is true only to the packets that have not been learned by
the ARL (Address Resolution Logic) table yet.