we have some troubles with Yealink T58 Phones, specifically with audio quality on stablished calls, when a call is placed and answered, the volume decrease until stop to hear anything, and then, after a couple of seconds the volume comes back to a normal volume. We tried to change opus codec to G722 but this happends again, there’s no Lagged, UNREACHABLE or another issues with the phone, even when in the network is configurated with a voice VLAN.
All the SIP signalling is on TLS with an SBC to delegate to asterisk only to process media and the SBC works with signalling and dialplan restrictions.
Yealink can’t be able to detect the real issue even with YDMS system, because all the calls with this issue is marked as a good or excelent call because there is no packet loss.
I operate a couple T58s myself and I cannot confirm that there is a problem with these phones. It’s likely your network configuration. Using G.722 and/or Opus is generally (but not under certain circumstances) a bad idea for a couple of reasons and I don’t see any reason why one should use a VLAN. The information you supplied does not allow to name possible problems, but if you experience transcoded audio streams in a path, this has far more influence on the quality of the calls than anything else.
We have installed in that building 200 ip phones between T58, T54 and T53, in three different floors, even for good practices we decide to use different VLAN’s, we use wideband codecs to give to our users a “better quality” against G711
We change the principal phone whith this issue twice with the same model, and still happends, we cant change for another model because the user can’t change the 200 phones
Is there any transcoding happening. If not it really has to be the phones. Otherwise, use tcpdump and wireshark to extract the RTP streams and see in which stream(s). an independent G.722 codec has problems. If wireshark still doesn’t decode G.722 natively, there are guides, on the web, as to how to get the raw RTP content and decode it with sox.
G.722 is a sub-band ADPCM codec, and the A in ADPCM stands for adaptive, which effectively means the gain is adjusted. However the code is designed so that failures of the receiver to correctly calculate the required gain, due to transmission errors, will self correct over time and you would have to be consistently losing a lot of low magnitude samples, for the gain to drift down and stay down, or there would have to be an implementation error in the codec.
Incidentally, if your primary concern is audio quality, you should not include G.729 in your allowed codecs, as it has a significantly lower mean opinion score than G.711.
As I see, the phone reject some packets at the begining of the call but after a couple of packets it allow the incoming RTP. I have the wireshark call but can’t be rebuilded for TLS encryption
Just enable level 6 diagnostic, export from the web interface of the phone and open a ticket on https://ticket.yealink.com/.
Hope you got more luck than me, support guys said T58 is end of life product…