Tweet
[so cool] IP Phones and Network Management
IP Phones and Network Management
I've found that IP Phone vendors have done a poor job of instrumenting their phones to be remotely monitored and managed. There are several things that need to be made more visible. One is detecting operational call problems. Having the phones send data to their respective call controller is acceptable, but the call controller needs to send that data on to a management station, probably in an asynchronous message like syslog as well as be available via SNMP polling.
For example:
Cisco's phones allow you to see the delay, jitter, and packet loss stats by pressing buttons on the phone. This data is only for the average across the duration of the call. So any call that has a 30 second burst of high jitter over a much longer call will make the burst virtually invisible.
Avaya allows the phone to export the RTCP (RealTime Control Protocol) to a management station, providing better granularity to call performance parameters. Their problem is that there can be only one destination and Avaya's product for receiving the RTCP stream doesn't have a way to forward the stream to other management systems that need it.
Another nit is providing visibility into use of the phone's auxiliary data port. There doesn't seem to be a way to find out if the port is being used, the MAC address of the device that is connected to it, and the speed, duplex, performance counters, and error counters on the port. A vendor independent mechanism would be really nice, perhaps via a standard MIB in the phone, or in data returned to the call controller. This data will make it much easier to track down a specific user on the network and where that person's phone and workstation are located and to identify if there are problems with the workstation's connection.
My recommendation is that the vendors work towards making their VoIP infrastructure more easily monitored and managed. It will reduce their support costs and make their products favorable over other vendor products. Ultimately, a common set of solutions would be preferable over vendor-specific solutions.
Terry
For example:
Cisco's phones allow you to see the delay, jitter, and packet loss stats by pressing buttons on the phone. This data is only for the average across the duration of the call. So any call that has a 30 second burst of high jitter over a much longer call will make the burst virtually invisible.
Avaya allows the phone to export the RTCP (RealTime Control Protocol) to a management station, providing better granularity to call performance parameters. Their problem is that there can be only one destination and Avaya's product for receiving the RTCP stream doesn't have a way to forward the stream to other management systems that need it.
Another nit is providing visibility into use of the phone's auxiliary data port. There doesn't seem to be a way to find out if the port is being used, the MAC address of the device that is connected to it, and the speed, duplex, performance counters, and error counters on the port. A vendor independent mechanism would be really nice, perhaps via a standard MIB in the phone, or in data returned to the call controller. This data will make it much easier to track down a specific user on the network and where that person's phone and workstation are located and to identify if there are problems with the workstation's connection.
My recommendation is that the vendors work towards making their VoIP infrastructure more easily monitored and managed. It will reduce their support costs and make their products favorable over other vendor products. Ultimately, a common set of solutions would be preferable over vendor-specific solutions.
Terry
Comment