SPA3102 new firmware 5.1.10 ignores preferred codec

Unanswered Question

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 have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Alberto Montilla Fri, 02/13/2009 - 03:15

Dear Sir;

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.

Regards
Alberto

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....

Alberto Montilla Fri, 03/13/2009 - 07:39

Dear Sir;

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.

Regards;

Alberto



hotlavamedia Wed, 04/15/2009 - 22:51

Dear Alberto,

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.

Regards,

Arne

Alberto Montilla Mon, 04/20/2009 - 03:11

Dear Arne;

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

Regards
Alberto

hotlavamedia Tue, 04/21/2009 - 04:08

Dear Alberto,

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.

Regards,

Arne

Alberto Montilla Fri, 04/24/2009 - 06:00

Dear Sir;

I will reopen the investigation and let you know the result early next week.

Regards
Alberto

Alberto Montilla Tue, 04/28/2009 - 07:19

Sirs;

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.

Regards
Alberto

Alberto,
Apologies for the belated reponse, I thought i had sent you this email, but found it sitting in my "draft" folder in Outlook. I've sent you an email, but also replicated the email in this forum. Here is my repsonse;
Thank you, whilst I agree with most of what you say. It does not explain the fact that once a call transits the FXO (PSTN port), than all subsequent calls via the FXS, the ATA offers G711u ONLY even though other codecs are in the preferred list (this can be seen in the packet dumps - please have a look at filename "VM_post-via-gw0_G729_G711a_G711u_forceno_progressG711u" - ).
This behaviour is only since 5.1.10. A power cycle of the ATA resets it back to its senses. I suggest you lab up a SPA3102 v5.1.7 - run the tests and then upgrade to 5.1.10 and see the difference. You need to ensure the SPA3102 never has had 5.1.10 on it before.
Cheers.
encephalux Tue, 12/28/2010 - 08:42

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?


Thanks,


Costantino.

Nemphys Tue, 05/26/2009 - 05:47

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!

Alberto Montilla Wed, 05/27/2009 - 03:59

Dear Sirs;

An official defect has been opened. I'll keep you informed once we have a new firmware load with this issue fixed.

Regards
Alberto

Alberto Montilla Tue, 06/09/2009 - 03:16

Dear Sir;

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.

Regards;
Alberto

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. :)

Alberto Montilla Mon, 06/29/2009 - 03:59

Dear Sir;

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.

Regards
Alberto

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:///filename.bin.

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

Alberto,

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.

washraf Mon, 09/28/2009 - 17:16

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.

Alberto Montilla Thu, 10/08/2009 - 06:13

Dear Sir;

No fix is available yet. Workaround is to go back to FW version 5.1.7

Regards;
Alberto

hotlavamedia Tue, 02/16/2010 - 23:23

Alberto,

I take it that there has been no progress yet on fixes for the SPA3102 issues?

Regards,

Arne

Alberto Montilla Thu, 02/18/2010 - 01:59

Dear Arne;

You are right. Team is currently planning the next release. I'll let you know the outcome when it is firm.

Regards
Alberto

richardza777 Thu, 02/18/2010 - 11:43

amontill wrote:

Dear Sir;

No fix is available yet. Workaround is to go back to FW version 5.1.7

Regards;
Alberto

Hi Alberto,

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.

Kind Regards,

Richard

oncallit1 Sat, 02/27/2010 - 15:07

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?

David Harper Sun, 02/28/2010 - 18:11

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.

Cheers,

Dave.

oncallit1 Sat, 03/13/2010 - 19:18

Hi Dave -

Apologies for the long delay...

To answer your question, I reside in Australia and I can confirm that this issue I’m experiencing is certainly related to this new F/W 5.1.10..

In frustration; I ended up downgrading to 5.1.7; changed nothing, no settings, no tinkering what so ever and is working as expected without the issues I had described in my earlier post.

Can’t really be bothered going back to 5.1.10 just to get screenshot of bottom of pstn line tab, although it has remained unchanged after downgrade so it should be the same – yet it’s now working fine regardless..

I am aware of the hang-up tone for Aus, as far as I know I’m using the correct one; that being: 425@-30,425@-30;1(.375/.375/1+2)

Michael

David Harper Sat, 03/13/2010 - 21:20

Hi Michael,

Thanks for the feedback.  I've seen a few reports now of people running into this sort of issue with the 5.1.10 firmware and being fixed by a downgrade.  This is pretty obviously a software issue, and has been raised with engineering.  Hopefully we should have some feedback for you soon.

Cheers,

Dave.

pqarmitage Thu, 04/22/2010 - 04:09

I have today received an email notication to say that 5.1.7 is obsolete, and I also see that there is a file SPA3102_5.1.10.zip dated 19 April 2010.

Is this the same 5.1.10 that is causing the problems identified in this thread? With 5.1.7 being obsoleted, what version should we regress to to resolve the issues in 5.1.10?

Is there any news of when a new version, resolving the issues, might be available? I am desperate to be able to upgrade my firmware, but it doesn't appear to be safe to move to 5.1.10.

occamsrazor Sat, 07/03/2010 - 03:38

I registered to this forum just to say:

What on earth is going on? The issue in this thread is well over a year old, and there seems to be no sign of it being resolved. When Cisco took over the Linksys products I had hopes that the aging but still excellent SPA-3102 might actually get properly supported with newer firmware, but judging by the progress so far this doesn't seem to be the case. Can we have an update please?

hotlavamedia Tue, 07/20/2010 - 07:50

Cisco Support,

can you please confirm or otherwise if the SPA3102 continues to be a Cisco supported product?

Regards,

Arne

annoyedbycisco Wed, 07/28/2010 - 19:10

Has anybody tried the new firmware (3.3.6) yet?

http://tools.cisco.com/support/downloads/go/ImageList.x?relVer=3.3.6&mdfid=282414112&sftType=Analog+Telephone+Adaptor+%28ATA%29+Firmware&optPlat=&nodecount=2&edesignator=null&modelName=Cisco+SPA3102+Voice+Gateway+with+Router&treeMdfId=278875240&treeName=Voice+and+Unified+Communications&modifmdfid=null&imname=&hybrid=Y&imst=N&lr=Y

What an ANNOYING procedure just to d/l a simple file!

I think these cisco web designers have nothing really to do except of to put more hurdles in our way!

anyhow, please give a feedback if you tried the new f/w, thanks!

micronanopico Thu, 07/29/2010 - 00:19

It ain't new. It's the original firmware that came with the first batch of 3102s, like mine.

They probably decided to re-post it on the website, that's why the "new" date against it.

If you open the zip file, notice within it the true date of July 2006 against the files.

BTW, I agree that their download process is indeed annoying.

annoyedbycisco Thu, 07/29/2010 - 19:31

Thanks for the info, was wondering about the backwards numbering too.

Another "nice job" done by the cisco web designers (I know it is an oxymoron to call them designers, but even a horrible design as this cisco site is still a design of some sord)

And of course hail to the engineers (again, if one can call them so), for messing things up even more instead of correcting them.

I am sure they are all proud.

bugmenolonger Fri, 07/03/2009 - 08:37

Hi Alberto,

I live in the UK and use a BT line.

I have setup my SPA-3102 to use the PSTN line (BT line in this case), when I dial 9.

I rarely use PSTN, apart from using the 1471 BT service

This BT service is an automated voice telling you what number called you last.

Using the test firmware you posted a few days ago I tried dialling 9 (for PSTN) 1471 #  and I get no response.

Tried twice and still no response.

Flashed my SPA-3102 back to the 'official' 5.1.10 and now when I dial 91471# I can hear the automated voice.

I therefore believe your test firmware is causing more problems than what it was supposed to solve.

Just my 2p.

Thank You for your assistance!

Alberto Montilla Mon, 07/06/2009 - 06:59

Hi;

Thanks for the info. I'm informing engineering of this issue on the test firmware.

Regards

Alberto

Actions

This Discussion