Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Downgrading firmware on 9611
- Thread starter IVRGirly
- Start date
For the most part, yes, you can load any firmware version on a phone.
Most recently manufactured phones are an exception to that:
9611G Global – Minimum Software Release The 9611G IP Deskphone Global (Comcode 700504845/700501429, Model ID 9611GD02B) must use either Deskphone SIP 6.4.0.33 or later software or Deskphone H.323 6.4.0.14 or later software. Attempts to downgrade these models to lower versions of software will be rejected. If these models are implemented in an environment that uses lower versions of software for other 9601/9608/9608G/9611G/9621G/9641G IP Deskphones, it is recommended to use a mechanism to differentiate the software loads such as different HTTP servers or different GROUPs.
Most recently manufactured phones are an exception to that:
9611G Global – Minimum Software Release The 9611G IP Deskphone Global (Comcode 700504845/700501429, Model ID 9611GD02B) must use either Deskphone SIP 6.4.0.33 or later software or Deskphone H.323 6.4.0.14 or later software. Attempts to downgrade these models to lower versions of software will be rejected. If these models are implemented in an environment that uses lower versions of software for other 9601/9608/9608G/9611G/9621G/9641G IP Deskphones, it is recommended to use a mechanism to differentiate the software loads such as different HTTP servers or different GROUPs.
You would normally do a downgrade by downloading the required zip/tar file from support.avaya.com and putting those on your http server. NOTE however that the currently shipping 9611G (the ones without English letters on the faceplate) will not accept any firmware earlier than 6.4.0. The latest available firmware is 6.6.0.
- Thread starter
- #4
Thank you both for the info, yes we have Deskphone H.323 6.4.0.14, so basically it is a no go on the downgrade. We are experiencing jitter and static. Without bringing in the network teams right now, we wanted to test that out. What are either of your thoughts on needing to upgrade the main CM server to 6.3? Or does this seem to be a network issue?
Network issue! And, just because you're running 6.4.0.14 doesn't mean you can't downgrade. You can't downgrade if your set's comcode/Avaya part # is the more recent release of 9611. So, if 700504845 or 700501429 isn't the # on the sticker on the bottom of the phone, you ought to be OK.
Live, if you trace the phone (and can reliably reproduce the problem) CM will print jitter and packet loss every 10 seconds if that call is using an Avaya DSP on a medpro or gateway. You can perhaps disable direct IP audio on the station form to force it to use a DSP to let you get those stats.
Further, depending on how QoS is setup and if you're in a WAN scenario, it can be beneficial to tie down audio between those sites to DSPs such that they're in charge of getting the audio between the 2 endpoints.
Example: You've got voice vlans for phones at each site, a core vlan for servers and gateways at each site, and QoS is setup to only prioritize traffic from either site if coming from the core VLANs. Disabling shuffling/direct IP between those network regions would make phones at either end of a WAN send audio to DSPs in their local core VLANs rather than directly to one another. QoS in the network might treat that differently.
Live, if you trace the phone (and can reliably reproduce the problem) CM will print jitter and packet loss every 10 seconds if that call is using an Avaya DSP on a medpro or gateway. You can perhaps disable direct IP audio on the station form to force it to use a DSP to let you get those stats.
Further, depending on how QoS is setup and if you're in a WAN scenario, it can be beneficial to tie down audio between those sites to DSPs such that they're in charge of getting the audio between the 2 endpoints.
Example: You've got voice vlans for phones at each site, a core vlan for servers and gateways at each site, and QoS is setup to only prioritize traffic from either site if coming from the core VLANs. Disabling shuffling/direct IP between those network regions would make phones at either end of a WAN send audio to DSPs in their local core VLANs rather than directly to one another. QoS in the network might treat that differently.
- Thread starter
- #6
That is what we think. Prognosis shows it having up to 85% packet loss. After another day of troubleshooting, we have found that this happens approx 10 minutes and it affects only one way traffic. Meaning, anyone hanging off of the new gateway will receive the 5 second interruption every approx 10 minutes, however the person on the other end never hears the packet loss. Network Assessment never showed an issue a week and a half ago. I guess my question is this, thoughts on where the issue is........WAN, LAN or some timer within the gateway that could be going off (or a certain threshold).
- Thread starter
- #8
montyzummer
IS-IT--Management
There are three places , system features , ip network region or on the individual station form pg 2 , the setting is direct ip-ip connections.
APSS (SME)
ACSS (SME)
ACIS (UC)
APSS (SME)
ACSS (SME)
ACIS (UC)
- Thread starter
- #10
here's another thought, is there a buffer within the unit itself that resets if it reaches a certain threshold? the poor voice quality can be best described (at least from what I hear) is a mechanically tone......similar to an IVR dialing an ext). the 1 way audio outage only happens on the new phone and lasts up to 5 sec.
The jitter buffers are generally set to 20ms. Its just a controlled delay in the conversation to prevent it playing in true real time as you'd get cuts and drops as soon as some packets didn't arrive in time.
In between the concerned network regions, you can turn off shuffling on page 1 of the network region forms.
Also, are you doing any call recording? Or is there anything else that could be involved in the speech path?
In between the concerned network regions, you can turn off shuffling on page 1 of the network region forms.
Also, are you doing any call recording? Or is there anything else that could be involved in the speech path?
montyzummer
IS-IT--Management
You also couldtTry turning off inta region direct audio , but follow the troubleshooting logically as kyle suggests , turn off shuffling first ,list trace and status the stations concerned and learn what resources are being used for signalling and specifically audio.
APSS (SME)
ACSS (SME)
ACIS (UC)
APSS (SME)
ACSS (SME)
ACIS (UC)
- Status
Similar threads
- Locked
- Question
- Locked
- Question