technology, networking and IP telephony
Posts tagged SUCCESSION
Link Flap and Succession Voice Gateway Media Cards
0August 22, 2008
The Nortel Ethernet Routing Switch 8600 supports a feature called link flap detect. This feature is designed to detect a port whose link is flapping up and down and potentially disable the port and/or issue an SNMP trap. The feature allows the configuration of a specific frequency and interval which can be used to fine tune control of the feature.
A few years ago we deployed about 25 Voice Gateway Media Cards (VGMC) across five different Nortel Call Server 1000Ms. We almost immediately started to notice a problem between the VGMCs and the ERS 8600 switches. The VGMCs would link up and link down multiple times as they booted up. While there is technically no real problem with the VGMC you can run straight into a road block if you reboot the card multiple times in a short period of time. Without getting to crazy on the explanation the ERS 8600 switch would potentially disable the switch port(s) that connected to the VGMCs if they were rebooted to often during a 60 minute period. The problem was only observed while the VGMCs were booting up, once the VGMC was up and running the problem never occurred. I believe the link flap detect feature is enabled by default unless specifically disabled.
This may be an old problem that might have already been corrected by Nortel but I still have the link flap detect feature disabled on the Ethernet Routing Switch 8600s that connect to our Nortel Voice Gateway Media Cards.
ERS8600:5# config sys link-flap-detect interval 60 ERS8600:5# config sys link-flap-detect frequency 10 ERS8600:5# config sys link-flap-detect auto-port-down disable ERS8600:5# config sys link-flap-detect send-trap enable
The configuration can be confirmed using the following command;
ERS8600:5# show sys link-flap-detect general-info Auto Port Down: enable Send Trap : enable Interval : 60 Frequency : 10
The frequency defines how often a port can go down, where the default is 10 (times). The default interval is 60 minutes; therefore the port will be disabled if the port goes down 10 times within 60 minutes.
Cheers!
What does "watchdog timeout" mean on Nortel wireless phones?
9August 6, 2008
It was a challenge to understand all the different heartbeats, timeouts and protocols that were in play between the handset and the Nortel 2245 wireless gateway and ultimately the Nortel Succession Signaling Server. With any Nortel IP phone running a UNIStim protocol there is a watchdog timer on the phone that counts down from 200 seconds. The watchdog timer must be reset by a watchdog reset (heartbeat) message that gets sent out from the Nortel Succession Signaling Server. This watchdog reset gets sent every 30 seconds. If a handset, remember now any Nortel IP handset that is running a UNIStim protocol such as the i2002, i2004, 1120e, 1140e, 1150e, 2210, 2211, 6120 and 6140 misses too many of these heartbeats the phone will reset itself usually displaying the message “watchdog timeout” indicating that the watchdog timer has reached zero and the phone is attempting to recover from the problem by resetting itself. With the Nortel 2210, 2211, 6120 and 6140 you also have the SVP heartbeats and timeouts to worry about.
If you have some IP phones that are generating “watchdog timeout” message your probably loosing packets somewhere in your network. With that said I would advise anyone with such a problem to immediately contact their voice reseller and make sure their Succession Call Server and Signaling Server have the latest and greatest DEP (patches) list. Once that’s complete you’ll need to go about the task of isolating the possible locations where you could be dropping packets. If it’s a wired IP phone then the problem is much easier to troubleshoot and isolate. If it’s a wireless phone then you’ll have a few extra steps. You’ll obviously need to make sure that you have QoS (DiffServ) up and working within your environment and you’ll need to make sure that you have SVP support enabled on your wireless infrastructure. SpectraLink (recently acquired by Polycom) actually has a library of documents to help customers configure their wireless infrastructure properly to support the SpectraLink handsets.
Cheers!
Correction: August 19, 2008
The watch dog interval is actually 200 seconds long and not 120 seconds as originally posted.
Update: August 24, 2008
It would seem that this article has generated a lot of interest including several inquiries by Nortel. So I thought I would try to add some additional explanation to help more clearly describe the problems and experiences I’ve had the Nortel 2211 and 2210 wireless handsets. I won’t rewrite the original because I don’t think there is anything wrong with it, other than perhaps missing some attention to the specific details.
The Motorola WS5100 v3.x and RFS7000 v1.1 was technically broken for anyone using the Nortel 2211/2210/6120/6140 wireless handsets. The phones would often reset while idle, because of a buffering issue on the Motorola AP300 access port. These problems have been resolved (as far as my testing indicates) in the Motorola WS5100 v3.2 and RFS7000 v1.2 software release. Through our troubleshooting of this problem we learned a great deal about the Spectralink Voice Priority protocol and the UNIStim protocol. In short the Nortel wireless handsets will go into PSP (Power Save Polling) for approximately 1.5 seconds, during that time the wireless handset turns off it’s radio to help save power and preserve the battery life. The problem occurs while the phone is idle because of the PSP mode, this is why no problems are ever reported while the phone is off-hook and actively being used. While the wireless handset is in PSP mode the wireless network is responsible for buffering any packets that are sent to the handset. The SVP protocol and UNIStim protocol can generate a lot of packets causing the wireless network to discard some packets while the phone is in PSP mode. These discarded packets can, depending entirely on the timing, cause the phone to either reset or the phone to be unregistered from the Succession Signaling server.
I’ve been asked by quite a few people what can be done to help alleviate any potential issues?
- The wireless infrastructure should be configured to support the SVP protocol
- QoS (DiffServ) should be set to “Trusted” on every Ethernet switch port that will be used to connect the different equipment (Succession Signaling Server, Succession Voice Gateway Media Card, 2245, wireless infrastructure)
- Design the wireless infrastructure so there is at least -60 dB of signal available and no more than 7 wireless handsets connected to a single access point/access port.
With all that said Nortel has literally just released v97.072 software for the Nortel 2211/2210 wireless handsets. While the release notes don’t seem to indicate any changes that are specific to “watchdog” issues it might be worth giving it a shot.
Cheers!
Update: Friday September 12, 2008
I’ve placed a copy of the Nortel document WLAN IP Telephony Installation and Commissioning (v3.3) on my website. This document should be a great help to many folks that are having issues with Nortel 22×0 and 61×0 wireless handsets.
Succession Signaling Server – Tips Part 2
1May 28, 2008
by Michael McNamara in VoiceOverIP
In the first part of this two post series I gave you a small sample of some CLI diagnostic commands that are available in the Succession Signaling Server v4.5. In this post I’m going to get a little more detailed and focus on some very specific commands used for troubleshooting voice quality in a VoIP network.
For the purpose of this post we’ll assume that we’re using and i2004 (Phase 2) phone. These commands are available on i2002,i2004, and i2007 (Phase 2 phones only). And also available on the 1120e/1140e and 1150e (they might be available on the i2050 softphone).
With the phone online you can remotely command the phone to perform a number of basic network troubleshooting commands as well as retrieve detailed network statistics. From the CLI interface of the Succession Signaling Server you can issue the following commands;
rPing <TN | IP>, <dest>[,<count>]
This command will instruct the phone to ping an IP address.
oam> rPing 10.1.198.50, 10.1.240.40, 5 27/05/2008 18:16:34 LOG0006 VTM:rPing Report from set (10.1.198.50) 64 bytes packets received from IP 10.1.240.40 27/05/2008 18:16:34 LOG0006 VTM:rPing Report from set (10.1.198.50) ICMP sequence is 0 27/05/2008 18:16:34 LOG0006 VTM:rPing Report from set (10.1.198.50) round trip time in ms: 20 27/05/2008 18:16:35 LOG0006 VTM:rPing Report from set (10.1.198.50) 64 bytes packets received from IP 10.1.240.40 27/05/2008 18:16:35 LOG0006 VTM:rPing Report from set (10.1.198.50) ICMP sequence is 1 27/05/2008 18:16:35 LOG0006 VTM:rPing Report from set (10.1.198.50) round trip time in ms: 20 27/05/2008 18:16:36 LOG0006 VTM:rPing Report from set (10.1.198.50) 64 bytes packets received from IP 10.1.240.40 27/05/2008 18:16:36 LOG0006 VTM:rPing Report from set (10.1.198.50) ICMP sequence is 2 27/05/2008 18:16:36 LOG0006 VTM:rPing Report from set (10.1.198.50) round trip time in ms: 20 27/05/2008 18:16:37 LOG0006 VTM:rPing Report from set (10.1.198.50) 64 bytes packets received from IP 10.1.240.40 27/05/2008 18:16:37 LOG0006 VTM:rPing Report from set (10.1.198.50) ICMP sequence is 3 27/05/2008 18:16:37 LOG0006 VTM:rPing Report from set (10.1.198.50) round trip time in ms: 20 27/05/2008 18:16:38 LOG0006 VTM:rPing Report from set (10.1.198.50) 64 bytes packets received from IP 10.1.240.40 27/05/2008 18:16:38 LOG0006 VTM:rPing Report from set (10.1.198.50) ICMP sequence is 4 27/05/2008 18:16:38 LOG0006 VTM:rPing Report from set (10.1.198.50) round trip time in ms: 20 27/05/2008 18:16:38 LOG0006 VTM:rPing Report from set (10.1.198.50) 64 bytes packets received from IP 10.1.240.40 27/05/2008 18:16:38 LOG0006 VTM:rPing Report from set (10.1.198.50) 5 packets transmitted 5 packets received, 0 packets lost 27/05/2008 18:16:38 LOG0006 VTM:rPing Report from set (10.1.198.50) minimum round trip time in ms: 20 27/05/2008 18:16:38 LOG0006 VTM:rPing Report from set (10.1.198.50) average round trip time in ms: 20 27/05/2008 18:16:38 LOG0006 VTM:rPing Report from set (10.1.198.50) maximum round trip time in ms: 20 oam>
rPingStop <TN | IP>
This command will instruct the phone to stop pinging.
rTraceRoute <TN | IP>, <dest>, <count>
This command will instruct the phone to trace the route of the destination address.
oam> rTraceRoute 10.1.198.50, 10.1.240.40, 3
27/05/2008 18:22:56 LOG0006 VTM: rTraceRoute Report from set (10.1.198.50):
1 -- 10.1.198.1: 0ms 0ms 0ms
27/05/2008 18:22:56 LOG0006 VTM: rTraceRoute Report from set (10.1.198.50):
2 -- 10.1.144.40: 20ms 20ms 20ms
27/05/2008 18:22:56 LOG0006 VTM: rTraceRoute Report from set (10.1.198.50):
3 -- 10.1.144.8: 20ms 20ms 20ms
27/05/2008 18:22:56 LOG0006 VTM: rTraceRoute Report from set (10.1.198.50):
rTraceRoute completed !
oam>rTraceRouteStop <TN | IP>
This command will instruct the phone to stop the trace route.
RUDPStatShow <TN |IP>[, <clear>]
This command will display the RUDP statistics from the phone.
oam> RUDPStatShow 10.1.198.50 27/05/2008 18:27:19 LOG0006 VTM:RUDPStatShow Report from set (10.1.198.50) Number of Message Sent: 451 27/05/2008 18:27:19 LOG0006 VTM:RUDPStatShow Report from set (10.1.198.50) Number of Message Received: 153149 27/05/2008 18:27:19 LOG0006 VTM:RUDPStatShow Report from set (10.1.198.50) Number of Retries: 1 27/05/2008 18:27:19 LOG0006 VTM:RUDPStatShow Report from set (10.1.198.50) Number of Resets: 0 27/05/2008 18:27:19 LOG0006 VTM:RUDPStatShow Report from set (10.1.198.50) Uptime of Current TPS Registration: 0days 4hours 19minutes 8seconds
You can also append a value of 1 to the previous query to clear the statistics;
oam> RUDPStatShow 10.1.198.50, 1 RUDPStatShow: clear statistics after RUDPStatShow 27/05/2008 18:29:04 LOG0006 VTM:RUDPStatShow Report from set (10.1.198.50) Number of Message Sent: 0 27/05/2008 18:29:04 LOG0006 VTM:RUDPStatShow Report from set (10.1.198.50) Number of Message Received: 0 27/05/2008 18:29:04 LOG0006 VTM:RUDPStatShow Report from set (10.1.198.50) Number of Retries: 0 27/05/2008 18:29:04 LOG0006 VTM:RUDPStatShow Report from set (10.1.198.50) Number of Resets: 0 27/05/2008 18:29:04 LOG0006 VTM:RUDPStatShow Report from set (10.1.198.50) Uptime of Current TPS Registration: 0days 4hours 20minutes 53seconds
eStatShow <TN | IP> [, <clear]
This command will display the Ethernet statistics from the phone.
oam> eStatShow 10.1.198.50 27/05/2008 18:30:55 LOG0006 VTM:eStatShow Report from set (10.1.198.50) Duplex Mode: 1 27/05/2008 18:30:55 LOG0006 VTM:eStatShow Report from set (10.1.198.50) Auto Negotiate Protocol Received: 0x3 27/05/2008 18:30:55 LOG0006 VTM:eStatShow Report from set (10.1.198.50) Interface Speed: 1 27/05/2008 18:30:55 LOG0006 VTM:eStatShow Report from set (10.1.198.50) LAN Priority Bit: 0 27/05/2008 18:30:55 LOG0006 VTM:eStatShow Report from set (10.1.198.50) VLAN ID: 1 27/05/2008 18:30:55 LOG0006 VTM:eStatShow Report from set (10.1.198.50) Packet Collision Peg Count: 0 27/05/2008 18:30:55 LOG0006 VTM:eStatShow Report from set (10.1.198.50) CRC Error Peg Count: 0 27/05/2008 18:30:55 LOG0006 VTM:eStatShow Report from set (10.1.198.50) Frame Error Peg Count: 0
As with the RUDPStatShow command you append a value of 1 to the query to clear the Ethernet statistics. I’ll skip the example but the command would be “eStatShow 10.1.198.50, 1″.
isetInfoShow <TN | IP>
This command will display the phone configuration and server information.
oam> isetInfoShow 10.1.198.50 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report (DHCPConfig) from Set (10.1.198.50) Terminal Type: i2002 Ph2 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report (DHCPConfig) from Set (10.1.198.50) Firmware Version: 0604DBG 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report (DHCPConfig) from Set (10.1.198.50) Hardware ID: 18-001765ffe0fc-6602 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report from Set (10.1.198.50) Firmware ID: 0x02 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report from Set (10.1.198.50) Manufacture Code: 0x001765 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report from Set (10.1.198.50) Color Code: 0x66 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report from Set (10.1.198.50) PEC Code: NTDU91AA 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report from Set (10.1.198.50) DHCP Server IP: 10.1.198.10 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report from Set (10.1.198.50) VLAN Priority: 6 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report from Set (10.1.198.50) VLAN ID: 14 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report from Set (10.1.198.50) Set IP Address: 10.1.198.50 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report from Set (10.1.198.50) Set Subnet Mask: 255.255.255.0 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report from Set (10.1.198.50) Set IP Gateway Address: 10.1.198.1 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report from Set (10.1.198.50) Boot Mode: 47 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report(Server Info) from Set (10.1.198.50) Server 1 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report(Server Info) from Set (10.1.198.50) Server IP = 10.1.240.40 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report(Server Info) from Set (10.1.198.50) Port Number = 4100 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report(Server Info) from Set (10.1.198.50) Action = 1 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report(Server Info) from Set (10.1.198.50) Retry = 5 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report(Server Info) from Set (10.1.198.50) Server 2 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report(Server Info) from Set (10.1.198.50) Server IP = 10.1.240.40 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report(Server Info) from Set (10.1.198.50) Port Number = 4100 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report(Server Info) from Set (10.1.198.50) Action = 1 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report(Server Info) from Set (10.1.198.50) Retry = 5 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report(Server Info) from Set (10.1.198.50) Server 3 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report(Server Info) from Set (10.1.198.50) Server IP = 0.0.0.0 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report(Server Info) from Set (10.1.198.50) Port Number = 0 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report(Server Info) from Set (10.1.198.50) Action = 1 27/05/2008 18:36:34 LOG0006 VTM:isetInfoShow Report(Server Info) from Set (10.1.198.50) Retry = 0
RTPStatShow <TN | IP>
This command will display network metrics and QoS values.
NOTE: You’ll need to be in PDT to execute this command from the CLI interface of the Succession Signaling Server. In order to enter PDT simply hold down the <CTRL> while typing the letters “PDT”.
pdt> RTPStatShow 10.1.198.50 27/05/2008 18:42:10 LOG0006 shell: RTPStatShow: IP 10.1.198.50 is not an active set, displays the statistics from previous call 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Far End IP address: 10.1.240.45 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Far End Port: 5224 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Packet Sent: 57 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Packet Received: 0 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Packet Received out of order : 0 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Pkt Loss: 0% 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Average Jitter: 0ms 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Latency: 0ms 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Listening R: 93 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Vocoder Type: 0 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Avg Net Loss Rate: 0.00% 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Avg Discard Rate: 0.00% 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Avg Burst Density: 0.00% 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Avg Burst Length: 0ms 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Gap Density: 0.00% 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Gap Length: 0ms 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Avg End System Delay: 5ms 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Avg Noise Level: 0dBm 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Avg Signal Power: 0dBm 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Round Trip Time Avg: 0ms 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Local Round Trip Time Avg High: 0ms 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Remote Listening R: 0 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Remote Avg Net Loss Rate: 0.00% 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Remote Avg Discard Rate: 0.00% 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Remote Avg Burst Density: 0.00% 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Remote Avg Burst Length: 0ms 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Remote Gap Density: 0.00% 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Remote Gap Length: 0ms 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Remote Avg End System Delay: 0ms 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Remote Avg Noise Level: 0dBm 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Remote Avg Signal Power: 0dBm 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Remote Round Trip Time Avg: 0ms 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Remote Round Trip Time Avg High: 0ms 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Remote Packet Loss: 0% 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Remote Average Jitter: 0ms 27/05/2008 18:42:10 LOG0006 VTM:RTPStatShow Report (RTCP-XR) from Set (10.1.198.50) Remote Latency: 0ms
Well by now you’re probably asking yourself what does all this mean. Well hopefully you aren’t completely lost. The first few commands are used to test basic connectivity, rPing and rTraceRoute. You would use these commands to make sure that an IP phone could communicate with a VGMC (Voice Gateway Media Card) or perhaps even another IP phone. Once you know you have basic network connectivity then you might need to look at some of the network statistics. Perhaps there is an auto-negotiation issue or perhaps there is too much packet loss leading too poor voice quality.
Note: did you know that you can perform pings an trace routes from the phone itself? After the phone has successfully booted and is connecting to the Nortel Call Server just press the “Services” key twice and select “Network Diagnostic Tools”.
Cheers!
