Hello to all,
I’m experiencing problems with the quality of the voice with calls coming from outside through my pjsip trunks. This problem has been manifesting itself for some weeks, in general the feeling is to speak through a tube(there is no delay or jitter, maybe just a little sometimes,and voice is always bidirectional).
I would like to ask a noob question, in this screen the word “lost” refers to the lost packages? and if so, does it represent a percentage? like 20% of all packages?
To start, I would remove g729 from phone, extension and trunk configs, using alaw as the preferred codec. On your fast line, the bandwidth savings of G.729 is insignificant and the quality improvement with G.711A is quite noticeable, especially when the remote party is on a mobile or otherwise using a compression codec. This also makes it easier to debug the remaining quality issues.
20 lost packets on a 6-minute call is significant, but far from awful. On average, 10 would have been lost while the extension user was talking and gone unnoticed. One would have occurred during pauses in the remote party’s speech and also gone undetected, so a careful listener would have heard a small glitch about once every 20 seconds. While not wonderful, this is better than a typical mobile call; I suspect that your trouble is primarily caused by some other impairment not shown in the stats.
Please describe the trouble in more detail. Are both outgoing and incoming calls affected? Does the remote party hear poor quality, or is it only the extension user? Is the problem always present or intermittent? If intermittent, have you noticed a pattern (e.g. occurs when there are many simultaneous calls, occurs during certain hours)? If calls are recorded (using normal FreePBX recording), does the recording also have poor quality?
thank you for your reply and pointing me to a direction.
ok I just removed the g729 codec so now endpoints trunks and asterisk pjsip settings have only this codec order g711a,g711u I will tell you Tomorrow if there is some improvement in voice quality.
ok thank you for this clarification
yes both incoming and outgoing and both extension and remote party are affected, mobile phones are for sure more noticeable.but some calls have really a good quality, let’s say about 30% are very good and 70% is like talking in a tube(delayor echo is not a problem,only the voice quality is affected)
I already tried to identify a pattern but is really random. sometimes one single call is a mess and sometimes 30 simultaneous calls are best quality, but I have noticied that not all simultanous calls have poor quality, lets say that my colleague have a poor quality conversation this doesn’t means that all other calls will have poor quality.
I didn’t tried this, I will try Tomorrow for the moment I have only changed all the codecs and rebooted all my routers and freepbx(uptime was arounf 2 mounths)
from my point of view I think that this is a provider related problem but before changing this one I want to be sure.
Sorry, but I disagree. The OP is in Ancona, Italy and assuming that most of his calls are within the EU, where alaw is king, alaw should be above ulaw.
Whether or not to include g722 is a more complex issue. Including it will permit HD (wideband) connections on intra-office calls. Unfortunately, Asterisk is not smart about codecs and on external calls that require G.711, it will transcode. This is a slight quality hit but also increases the server load significantly. If he has a trunking provider that can do g722 on VoLTE mobile calls, or one that bypasses the PSTN on calls to customers or vendors also using VoIP (and the server has sufficient horsepower), it’s probably worth it. Otherwise I’d stick with alaw.
No, it won’t. SIP negotiates all the codecs, on all the legs, and only transcodes if it can’t find a common path. If the provider only offers A, and the phone offers A, the entire path will be A (Unless you have changed the defaults, and removed/altered codecs).
Edit: I was wrong. However, I still believe that G722 should be the default, as the transcoding path is so fast and simple.
Honestly, the defaults are correct, and G722 should always be your first codec all the time.
Also, Transcoding G722/G711 is almost zero effort on the CPU, as the path is G722 → slin → G711. (core show translation paths g722 to see for yourself).
Possibly, on high end phones (Polycom, Cisco, etc.) this works well, but on my Yealink, Htek and Grandstream devices, the transcoded path sounds slightly worse to me. If I have a trunking provider that will give me wideband on a significant fraction of calls, it’s probably worth it use g722, even though ‘ordinary’ PSTN calls will be degraded a bit. But if the trunk is limited to ulaw or alaw, I’d rather avoid the transcode.
And in any case, since this thread is about a (narrowband) voice quality issue, I decided to not push my luck so avoided g722 altogether (at least for the OP’s testing).
Well. It’s obviously a codec issue now. @wassy83 just set everything to g711a/alaw/whatever you call it. Only use that. That should remove the issue. Then you can go and do some more work into looking into codecs and picking which one you want.
yes this is right and my provider doesn’t allow g722 codec (in activation email they provide to me this order
G729br8, G729r8, G711alaw, G711ulaw, G723ar53, G723ar63, G723r53, G723r63, G726r16, G726r24, G726r32, G728, GSM-EFR, GSM-FR.)
I tried changing to alaw and receive some calls… nothing changed from endpoint side(except that now lost packet are always 0 or max 2 after pjsip show channelstats command), but I had a noticeable improvement on the remote side… at this point I think that there is something with my fanvil, maybe after an upgrade cause the difference with x-lite soft phone is really evident. I’m sad cause is so difficoult to understand where is the problem coming from… unfortunately I don’t have other kinds of ipphone to test
Confirm that the channelstats now show alaw on both sides.
Confirm that the tests with X-Lite are valid (going through the PBX as a normal extension, using the same trunking provider, etc.)
Your original post implied that internal (extension to extension) calls are good quality. If not, then there may be an issue with e.g. a PoE switch feeding the phones.
If internal calls are ok, perhaps the jitter buffer in the phones is not friendly to the pattern on your network.
Have you tried recording on the PBX?
If we can’t find anything obvious, I suggest capturing traffic with tcpdump on the PBX and/or with Fanvil’s Network Packets Capture feature and using the RTP analysis tools in Wireshark to see whether the problem is jitter, packet loss, poor audio from provider, etc.
yes inside quality is always very good (only sometimes I have a little of delay, but it is not absolutely relevant)
ok, I know that for pjsip trunks and extensions there is not jitter buffer configurable parameters in freepbx, in my fanvil phones I can’t find anything related to jitter buffer, but I have enabled VQ RTCP-XR to check a good and a poor quality call to got some info and this is the results
I tried to record conversations and the quality is so perfect that is like listening an mp3 music file, no way to compare with endpoint quality. what does this mean?
That the trunk quality (server to server) is good, but the leg from the server to the phone is where the problem is.
Remember, Asterisk is a back-to-back user agent, so calls from extension A to phone B are always actually two calls - from to the server and one from the server to the remote phone. Since the quality is good at the server, the problem is likely to be transcoding on the fly of the codecs in use on the extensions.
Experiment. Start with simpler codecs, like g722 and aLaw (since you’re not in the US). You can try different codecs, but remember that you only get a vote on one leg of the entire conversation (the one from your PBX to your phones). The rest of the parameters are negotiated with servers and providers’ equipment that you have no control over.
Once you’ve got a codec set that works on the local phones, connect it up. Things like cell phones and remote PBX systems will communicate and negotiate the “best” codec (typically aLaw or uLaw) and set up the environment from there.
This is most puzzling, because your tests have ruled out every likely explanation: The recording shows that audio from the trunk is good. Extension-to-extension calling shows that the LAN can send clean audio from Asterisk to the phones and that the phones can play it faithfully. And, X-Lite shows that there is no issue with Asterisk passing audio from trunk to extension.
IMO a Network Packets Capture taken by the phone on a problematic call would be useful. We can see whether there is serious packet loss or excessive jitter, and also listen to audio reconstructed at that point. If possible, make the test call to a number that answers with a long IVR menu, so we’ll have a reference for comparison. Also, the RTP won’t contain anything personal and can be posted publicly.
this is exactly what I was thinking… honestly I think that there is something with these fanvils… like cpu overload on the ipphone itself… maybe this can explain all these issues… I will try tomorrow to post rtp analysis and report my results.many thanks
If possible, post the actual RTP. Put it in a .tgz file, which this forum will allow you to attach. Or upload it to some cloud service and post a link.
Also, describe the LAN devices between Asterisk and the phones. Do they have a separate PoE switch?
