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?
I'm not aware of bug on the setting of the codec in the product. We would need to see the SIP traces to understand whether this is a real issue or not. The SPA3102 works as any other ATA is a client, so it is actually the network (SIP server/SBC) the one who enforces the codec to use when using VoIP only (PSTN not involved), SPA3102 only follows its indication. If PSTN gateway is involved, the it will use G.711.
If you are a registered partner, I suggest you call our Small Business Support service at http://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html. They should be able to follow up your case.
If you are a reseller but has not partnered with us yet, I invite you to do so.
If you are an end user, please contact the reseller you purchased the units from.
I do not have a suport contract with Cisco. I have purchased the device outright a long time ago. I think you have missed what I may have been trying to say.
The problem/bug was introduced with firmware 5.1.10 - I've been using my VSP for years and know what codecs the VSP can do.
I do not have a PSTN line anymore. All calls are pure VoIP with my VSPs.
The VSP can do a number of codecs, including G.729a and G.711a & G.711u.
If I configure "Line 1" in such a way that I set the "Preferred Codec", "Second Preferred Codec & "Third Preferred Codec" to G.729a and also set "Use Pref Codec Only" to no - the call will go through as G.711u (I have done wireshark packet traces and the VSP offers a number of codecs, including G.729a, G.711a & G.711u) - however for some reason the SPA3102 seems to only want to do G.711u!
If I change the parameter "Use Pref Codec Only" to yes - meaning the SPA3102 will only allow the use of G.729a only and I place a call, the call will go through as G.729a - which proves that the VSP handles G.729a.
Setting the paramater to "Use Pref Codec Only" to yes is not desirable as if I use another VSP or place a fax call (using G.711a as FAX pass through) the call will fail.
Alternatively, if I leave "Preferred Codec" to G.729a and make the "Second Preferred Codec" G.711a and the "Third Preferred Codec" to G.711u and set "Use Pref Codec Only" to yes - the call will now instead go through at G.711a rather than G.711u
All it needs for Cisco is to lab up a SPA3102 with firmware 5.1.7 and test, then upgrade to 5.1.10 and see the difference.
I've gone as far as rolling back to 5.1.7 and factory defaulting the settings, and it seems despite rolling back the behaviour follows, which is most unfortunate.
Now I guess you can ignore what I am saying and wait until customers with support contracts see the problem and start logging faults, but that it really unacceptable. I can upload wireshark packet traces, but not in a public open forum....
I looked at your traces and provided a detailed response in the email...
ATA is behaving correctly. SIP/SDP offer operation is that end point offers one or a set of codecs to the network, ordered in priority, however the network is free to select any of the offered codecs. Softswitch/SBC algorithms determines the codec used (and sent to the ATA on the 183 or 200 message). Typical reasons for deciding one codec or another is related to codec resources (e.g. G729 codec consumes more resources than a G711 codec, so the network may select a G711 codec when it depletes its G729 codec resources or simply randomly to ensure load balancing)...
If you want to enforce G729 use, you have several options:
(1) Configure the SBC/Softswitch to always grant G729 if it is on the offer
(2) Configure the SBC/softswitch to always grant the first codec on the list (in this case it will grant G729 if it is the ATA preferred codec).
(3) Configure the ATA to use preferred codec only.
Could you please re-investigate this issue. My testing along with others has conclusively confirmed the existence of this issue since the upgrade to firmware 5.1.10.
The simplest test to demonstrate and verify the issue yourself is:
1. Set G729a as preferred codec on Line 1.
2. Make/Receive a Line 1 call. The selected G729a codec will be honored and is displayed in Line 1 Status of Info tab.
3. Make/Receive a PSTN call.
4. Make/Receive a Line 1 call. The selected G729a codec is now ignored and G711u codec is now used for all Line 1 calls as is evident in Line 1 Status. This is the fault condition.
A reset will clear the problem until any PSTN call where the fault condition will reappear for all subsequent Line 1 calls.
Could you please keep us informed of any progress.
One question. Has any of you talked to the Service Provider about this issue? We dont see any faulty operation on the ATA...it is proposing a set of codecs to the network and it is matter of the network to honor it or to change to any codec on the list. It is normal operation.
If you requires always the use of G.729a then use preferred codec only.
I would suggest to talk to the Service Provider in order to check what they have changed on the network, as operation from ATA point of view looks ok...I mean according to the standards
thank-you for your response.
Yes - we have confirmed that the fault is occurring across a variety of different Service Providers.
Please investigate the information supplied by 'peterp' for further details.
I will reopen the investigation and let you know the result early next week.
I see your point now. I've escalated the issue to a higher level of support. I should be reporting the finding, if any, over the community.
I wanted to add my concern to the already long list about the situation of this product, since we are planning to use quite a few of them in 2011.
The date of both files [bin + exe] of the firmware that I've just downloaded is January 22nd, 2009, hence almost 2 years old, whereas last "official communication" on this blog is about 6 months old.
Can CISCO kindly provide an update, both in information and firmware, and possibly a roadmap for this product? or should we translate the silence as a lack of commitment, hence: should we look for options?
I confiurm the problem, too. After trying to make a call through PSTN, all VoIP (Line1) calls ignore CODEC preference (even if set to "Use pref codec only") and use PCMU instead. I was having dropped outbound calls (all inbound calls worked fine) and couldn't figure out why. After checking my asterisk debug logs, I realized that at some random points (not random anymore, it's when you have placed a PSTN call first), the SPA would invite with just PCMU, though both the device and asterisk and configured for G729 ONLY. I temporarily allowed ulaw on the asterisk side, which at least doesn't produce dropped calls, although it uses much more bandwidth than I would want.
Please fix this problem as soon as possible, I think it is quite a huge bug!
An official defect has been opened. I'll keep you informed once we have a new firmware load with this issue fixed.
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.
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.
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. :)
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
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.
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.
You are right. Team is currently planning the next release. I'll let you know the outcome when it is firm.
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.
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?
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.