This is the topology:
Codecs ulaw and h264.
Up image with NEW firmware: good audio one way.
Down with OLD firmware: good audio both ways.
Wireshark show in the upper right legend show problems on both firmware, but with new firmware (same settings): the audio is fragmented, metallic (only one way).
Can you please tell me what can I do before asking to manufacturer?
Hi.
If that works with the previous firmware and it doesn’t work with the latest, then this one seems messed up indeed.
Thank you for the feedback, I’ve opened a ticket with the manufacturer, the support said: “New version use less CPU, try to change position of the device.”
You know “supercazzola”, it seems I’m working with chinese manufacturers that right now are specializing on this.
BR
How… 
Really?
Turning left or righ? Up or down?
Strange response!
The answering doesn’t make sense.
This is from support@akuvox today:
Checked again and deeper, seems the problem of the voice is because two devices get too closer with each other. And no other voice problem could be found.
No one here has tried fw 220.30.3.7?
Anyway right now this firmware has disappeared from official site.
hahahaha. This is a clue!! 
To be honnest, there is no diaphony on the VoIP.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
Dear Colleagues,
months are passed, no solution camed up: Akuvox support released new firmwares, I’ve tried these out with bad results on:
With a set of Akuvox R20B doorphone while the same systems are running better with firmware 220.30.2.9.
Latest firmware tried was on 220.30.3.11.
Right now my workflow is:
All this wasted time is on my own at my expense, any advice on a better workflow?
Can anyone out there confirm it’is really satisfied with this new firmware?
This is what a call look like from wireshark:
BR
Given the number of installations and the very few complaints about the audio quality, it seems very unlikely that Asterisk is the problem. What you describe points into another direction.
Have evaluated the output of
rtcp set debug {on|off|ip} – Enable/Disable RTCP debugging
rtcp set stats {on|off} – Enable/Disable RTCP stats
rtp set debug {on|off|ip} – Enable/Disable RTP debugging
rtp show settings – Display RTP settings
recently?
Having that you then would need to describe your net. I would assume that you have a network or a more general hardware problem, but there is too little information to show that.
Thanks for your reply, I will enable the debug options that you’ve suggested.
The net is a Gigabit LAN: doorphone, PBX and phone connected to same switch.
I’ve asked to manufacturer a way to do some test with direct ip call, so we can exclude Asterisk, let’s see what will happen.
Thanks, BR
rtp show settings output:
General Settings:
----------------
Port start: 10000
Port end: 20000
Checksums: Yes
DTMF Timeout: 1200
Strict RTP: Yes
Probation: 4 frames
Replay Protect: Yes
ICE support: Yes
Attached both packages and asterisk logs
I don’t see any Acuvox device, only a Linphone softphone and FreePBX 16.
In wireshark you can add filter
ip.addr==10.7.208.154
this with exten 194 is the akuvox device
exten 105 is linphone client
Found it.
What are we supposed to hear? What I hear sounds fine to me.
Initially you said you are using G.711 u-law, but your pcap file says that you are using a-law. Doesn’t matter, but since you are also offering a lot of other codecs like opus, speex, etc, I am not sure whether you sometimes run into a necessity to transcode, which may cause a couple of problems (or not).
I’ve switched to a-law, actually there’s should be only a-law available.
You’re supposed to hear at x:
The inserted silence and wrong timestamps have nothing to do with these problems?
I don’t know. I need to check that with some samples at work, but if you can disable “silence suppression” that is probably something you should try.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
