We have a client that we handle networking, server, and workstation support for. They recently had their phone vendor upgrade their phones to an Avaya IPOffice 500v2 system with J-series handsets. We originally configured the network ports to be Data VLAN untagged and voice vlan tagged. We set the Avaya DHCP options and when we connected a phone it would endlessly reboot. If we connected it to an untagged port it would stop rebooting, but not connect, we could see the phone picked up the appropriate VLAN and configuration settings from DHCP. Resetting a phone and connecting it to a dedicated Voice VLAN port or Data VLAN port would allow the phone to stay on and if the settings pushed by DHCP were correct (minus L2Q and L2QVLAN tags) the phones would connect to the server and work just fine. During troubleshooting with the VOIP vendor we originally found that if we left a phone connect on a voice VLAN port then connect it to a tagged port it seemed to pick up the settings and work fine no longer rebooting, but this also only worked after a factory reset of the phone or if done right out of the box. It was decided at that time due to this bug that we would would put the phones on the Data VLAN, because we did have to daisy chain PCs through the phones.
Apparently the client has been having an issues with echo on some phone calls, while this is not usually an issue caused by network issues (most frequently this is caused by handsets or digital/analog handoffs and they do use a PRI not SIP trunks), the vendor wants to get the handsets on their own VLAN with QoS (they have a full gig network with less than 20 users and snmp has shhown the network is underutilized so QoS was not configured for any VLANs on the switch, there are also some issues with implementing QoS as well due to the model HP switch in place but that's irrelevant at the moment). The vendor wants to do this as they know if they go to Avaya for any support for the echo Avaya will make them get things on an isolated VLAN with QoS before they will provide any assistance.
I'm pretty sure the issue is actually the PRI handoff, I've administered VOIP systems before and have had this exact same issue, which was the handoff and a digital/analog handofff if the most frequent culprit for this type of issue. While the VOIP vendor does seem to agree with this the client did not want to go to SIP trunks though it was suggested when the new system was put into place, however, this seems to be related to additional costs the client believes would be incurred by moving to SIP. My general experience though has been going to SIP is no more expensive and often less expensive than a PRI or copper lines. I digress.
Anyways I am wondering if anyone has any experience with this, pr thoughts on the reboot issue. I've tried things like disabling STP on the port, disabling all protections for loop and so forth, we have seen that the phones do grab an IP on the Voice VLAN before they reboot. My research has found that this issue has occurred with Avaya handsets before, chiefly I have seem posts related to this occurring with 4600 series handsets and 1608 handsets. The only work around noted in any of the posts I found for those were the one I found earlier where we connected it to an untagged VOICE VLAN port then moved it to a hybrid port, however, that was no longer working when we tried it on Tuesday. They have upgraded to the most recent firmware for the phones, the switch is upgraded as well with the most recent firmware. The posts I found on this found the issue occurring with multiple switch vendors and while this did not happen with a 5 port managed switch that was configured I don't think it is the switch itself based on the posts I have found.
Any assistance is greatly appreciated.
Links I've found searching:
There were a couple other too but I cannot find them at the moment.
Apparently the client has been having an issues with echo on some phone calls, while this is not usually an issue caused by network issues (most frequently this is caused by handsets or digital/analog handoffs and they do use a PRI not SIP trunks), the vendor wants to get the handsets on their own VLAN with QoS (they have a full gig network with less than 20 users and snmp has shhown the network is underutilized so QoS was not configured for any VLANs on the switch, there are also some issues with implementing QoS as well due to the model HP switch in place but that's irrelevant at the moment). The vendor wants to do this as they know if they go to Avaya for any support for the echo Avaya will make them get things on an isolated VLAN with QoS before they will provide any assistance.
I'm pretty sure the issue is actually the PRI handoff, I've administered VOIP systems before and have had this exact same issue, which was the handoff and a digital/analog handofff if the most frequent culprit for this type of issue. While the VOIP vendor does seem to agree with this the client did not want to go to SIP trunks though it was suggested when the new system was put into place, however, this seems to be related to additional costs the client believes would be incurred by moving to SIP. My general experience though has been going to SIP is no more expensive and often less expensive than a PRI or copper lines. I digress.
Anyways I am wondering if anyone has any experience with this, pr thoughts on the reboot issue. I've tried things like disabling STP on the port, disabling all protections for loop and so forth, we have seen that the phones do grab an IP on the Voice VLAN before they reboot. My research has found that this issue has occurred with Avaya handsets before, chiefly I have seem posts related to this occurring with 4600 series handsets and 1608 handsets. The only work around noted in any of the posts I found for those were the one I found earlier where we connected it to an untagged VOICE VLAN port then moved it to a hybrid port, however, that was no longer working when we tried it on Tuesday. They have upgraded to the most recent firmware for the phones, the switch is upgraded as well with the most recent firmware. The posts I found on this found the issue occurring with multiple switch vendors and while this did not happen with a 5 port managed switch that was configured I don't think it is the switch itself based on the posts I have found.
Any assistance is greatly appreciated.
Links I've found searching:
There were a couple other too but I cannot find them at the moment.
