02-12-2009 11:21 PM - edited 03-21-2019 09:14 AM
I've recently upgraded to new firmware 5.1.10, however it seems it breaks the ability to adhere to the chosen "preferred codec".
For some reason, if i select G729a as my preferred codec, the unit will for some reason select G711u as the active codec to place the VoIP call. This behaviour was not evident with firmware 5.1.7 - and it's not a VSP issue.
I've tried to fatory default the unit to resolve the problem but no luck! Tried to factory default and roll back to 5.1.7 and then to 5.1.5(a) and then 3.2.10 and stil no luck. (I had a back up of my config from a few months ago whilst using t 5.1.7 and tried to restore to that, (in case the upgrade to 5.1.10 mangled some settings) after factory defaulting whilst running 5.1.7 and still no luck)
Anyway here is a thread with all the issues we've had http://forums.whirlpool.net.au/forum-replies.cfm?t=1130617
- there are many other users who now suffer this issue since upgrading.
So anyone from Linksys Cisco want to explain what is going on here?
05-27-2009 03:59 AM
An official defect has been opened. I'll keep you informed once we have a new firmware load with this issue fixed.
05-28-2009 01:38 AM
Do we have an ETA on the new firmware release to fix this defect? Do you have a defect ID?
Will the s/w 5.1.10 be retracted from market, as I don't see why other unsuspecting users should be affected by this defect.
06-09-2009 03:16 AM
We continue working to solve the issue, there is no ETA available yet.
5.1.10 will not be retracted, as this bug is not critical (the unit continues operating in most of the scenarios) but major.
06-28-2009 06:40 AM
Is there even a rough ETA on this? It's been a few weeks since an update. Would be nice to know of an approximate time frame. Weeks, months? Sorry, to nag. I don't want to tie you down to anything specific or commit you to a cut off date, but a nice loose approximate time frame would be _really_ nice. Save me from bugging you. I know timeframes do slip from time to time. :)
06-29-2009 03:59 AM
Attached you will find the test version of the firmware that fix the issue. I cannot mention when we are going to make it generally available. My suggestion is that you test it and confirm that works, if possible.
Unfortunately, I cannot comment on dates for delivering this FW as generally available yet, it is on planning purposes.
PS: As this is a test firmware, there is no executable version of it. You need to use tftp to upload it to the box. If you don't know yet the process, please go to the provisioning tab and include the [Provisioning] Upgrade Rule parameter in the format tftp://
Update: test version has been removed as it is not ready for release (there is a bug in the version). Will update with a new version as soon as available.
Message was edited by: Alberto Montilla
07-08-2009 03:54 AM
I've tested the "test" FW 5.1.10-0624h - and it seems to resolve the issue whereby after placing a call via FXO, the ATA would only offer G711u to the VSP SIP server for all subsequent FXS calls.
From my quick testing, after placing an FXO call, the ATA will now correctly offer the various codecs to the VSP SIP in the correct order (in my case G729a, G711a, G711u, G721, G723) for all subsequent FXS calls. So at least that's a positive. :)
However, it seems to have introduced other issues as noted in this thread already.
I'll continue to do some further testing with FXS calls and will report back if I find anything out of the ordinary.
09-28-2009 05:16 PM
What is the status of this issue? Do we have any fix now.
I have also this issue since I baught SPA3102 to replace my Grandstream hoping it would be more stable. However this particular bug has forced me to use this device as receive only for over 6 months. I use it with Asterix and G729 codec.
10-08-2009 06:13 AM
No fix is available yet. Workaround is to go back to FW version 5.1.7
02-16-2010 11:23 PM
I take it that there has been no progress yet on fixes for the SPA3102 issues?
02-18-2010 01:59 AM
You are right. Team is currently planning the next release. I'll let you know the outcome when it is firm.
02-18-2010 11:43 AM
No fix is available yet. Workaround is to go back to FW version 5.1.7
I am also experiencing this bug with 5.1.10.
I need this to work so I tried to download 5.1.7 but before downloading (here) the Cisco site wants me to agree to some terms, including:
"4. That you have a current and valid service contract that covers either the specific Cisco hardware chassis or device for which you are downloading software and/or the software image or subscription file update (e.g., for Intrusion Detection System) that you are downloading;
5. That Cisco reserves the right to: (a) charge you for, and you agree to pay for, software /signature file downloads to which you are not entitled, and (b) immediately suspend or terminate your access to this web site if you download software to which you are not so entitled."
However, I merely purchased the SPA3102 from a retailer and therefore do not have (nor require) a service contract with Cisco.
Am I entitled to download the 5.1.7 without being charged?
Thank you kindly.
02-22-2010 03:34 AM
Yes, please go ahead and download, you will not be charged.
02-23-2010 03:04 AM
Thank you Alberto.
02-27-2010 03:07 PM
I don’t mean to hijack this thread or go off topic, but I’ve found another bug with this latest FW release.
I too am experiencing the problems spoken about thus far, along with the following issue:
Once a call has been made out to local PSTN, you cannot seem to make VOIP calls afterward – I’ll explain.
Lets say I make a VOIP call to someone else, this works fine, I can hang-up and call through VOIP as much as I like. Then I go to make a call through PSTN, this is fine also, seems to work fine.
Now the moment I terminate the PSTN call, then go to make a VOIP call – I get ‘reorder tone’ constantly.
I’ve found that if I reset the 3102, (un power then re power) the unit functions as it should, so long as I don’t make a PSTN call followed by a VOIP call.
Anyone else confirm this or experiencing the same thing?
02-28-2010 06:11 PM
This actually sounds to me like an issue with the configuration of disconnect supervision on the PSTN line. Normally, the PSTN Line should detect a disconnect signal (in the form of power denial, battery-reversal, or disconnect tones) when the remote party hangs up and then disconnect the port. However, since every country uses different tones for disconnection, and many countries do not provide power denial or battery reversal, it is not uncommon for the SPA configuration to be incorrect. I'm a little puzzled though in that the call should also be torn down when the local handset hangs up, so it's possible I'm way off base here.
But in any case, could you possible attach a screenshot of the bottom of the PSTN Line config tab, after making sure you have selected advanced admin mode. Also, can you tell us which country you are located in. Just knowing the country is not a guarantee that we can figure out the correct disconnect tones since they often vary between telcos in the same country, and sometimes even telephone exchanges within the same telco, but at least it gives us a starting point.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: