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.