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?
02-13-2009 03:15 AM
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.
02-13-2009 10:58 PM
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....
02-16-2009 02:47 AM
I sent you an email separately to take your case...
03-06-2009 06:12 AM
Thank you. I've emailed you with captures and how to replicate the issue.
03-09-2009 03:32 AM
Thanks. Received the email. Will take a look at the issue.
03-13-2009 07:39 AM
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.
04-15-2009 10:51 PM
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.
04-20-2009 03:11 AM
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
04-21-2009 04:08 AM
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.
04-24-2009 06:00 AM
I will reopen the investigation and let you know the result early next week.
04-28-2009 07:19 AM
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.
04-21-2009 02:56 AM
12-28-2010 08:42 AM
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?
05-26-2009 05:47 AM
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!
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: