Recently after applying updates on my PBX (both v14 and v15) I have been having audio quality issues with my Grandstream ATA. It appears to affect all models and various versions of firmware on the ATA. Its only impacting the inbound audio. The call starts out fine and slowly begins to get distorted and a few seconds in it syncs up and is clear again. Its very consistent and I determined the length of the jitter buffer appears to have an impact. I have jitter buffer set to adaptive and the minimum size which makes this problem show up about every 15 seconds and takes about 5 seconds to get increasingly more garbled and then snaps back to clear in an instant. Almost feels like the incoming data is falling behind and then it re-syncs and its back to normal. I have noticed it been getting increasingly worse with new updates to freepbx.
It does not seem to be affecting any of my grandstream VoIP phones, only the ATA’s with Jitter (not 100% sure its the jitter setting but setting to big buffer clear gets more distorted longer, small buffer its less of an issue.
This issue is affecting multiple ATA, at different locations, different Internet connections and on different PBX’s (with different versions of freepbx). Started after I did updates. All of my PBX’s are updated about twice a month. I am not sure if its started to some extent 4 weeks, 2 weeks, or 2 days ago. Customers were complaining that there was “audio quality” issues for a few weeks but got really bad after the last updates a few days ago. Its not affecting any VoIP phones, only analog phones on Grandstream ATA’s. HXW4008, GXW4216, GXP4248 with various versions of firmware.
For the record, Jitter is a device level thing. Meaning the jitter setting on Asterisk has nothing to do with the Grandstream’s Jitter and vice versa. Jitter applies only to the endpoint that it is set on.
understood but CHAN_SIP and JITTER were a problem on EVERY grandstream devices I have, gxp2160, GXP2170, GXW4224, GXW4248, GXW4008. I have many phones and the issue was apparent on all of them no matter what version of firmware or freepbx I used. It started about once a minute there would be a little twirp, wasn’t bad but with recent changes to chan_sip it was getting worse with every upgrade. I had customer threating to drop my service it was getting so bad. Odd thing was it manly affected inbound Audio only, outbound wasn’t affected as much. Jitter set to low it was about once every 30-45 seconds, jitter set to high it was constantly an issue. So even if it was “device specific” there was an issue with all grandstream products I owned on 8 different PBX’s all on various different versions as well.
I dont care whos to blame, I just found that chan_pjsip solved the issue.
OK, Grandstream has never been a “top-of-the-line” vendor. They make decent devices. I have used Grandstreams on Chan_SIP and have not had the issues you are reporting. Jitter is the measurement of variance in the packet delivery in the data stream. The jitter buffer is what buffers those packets in order to try to process. If there is delay then Jitter rises and you could end up with missing packets of audio, etc.
While Chan_SIP has been around since the start of Asterisk basically and everyone knows it. The one thing that they don’t understand (especially if Asterisk is all they know) is that Chan_SIP, in the grand scheme of SIP stacks, is a very subpar SIP stack. Chan_SIP lacked things that many other SIP stacks (including PJSIP) had. It also handled certain things differently and out of the standards than the more standardized SIP stacks of the time. It handled NAT horribly compared to the rest.
Chan_PJSIP is the Asterisk adoption of the PJSIP stack which has been around almost as long as Chan_SIP. It is used in softphones and other embedded VoIP hardware projects. It follows the SIP standards much more closely and it also handles NAT better.
So yes, Chan_PJSIP looks to have fixed your issue but not because of the Jitter settings on Asterisk since those only apply to the packets Asterisk receives. It most likely fixed your problem because it has better handling of the SIP packets overall including better NAT handling which most likely resulted in your audio packets not being as delayed or other NAT/networking related issues.
The more Jitter you have happening and the lower the buffer is means that you are not buffering as many packets as you should be, and the missing/delayed packets haven’t been dealt with properly before passing the buffer cache through.
Pro Tip: High Jitter and audio problems that are caused by it are indications of networking problems or congestion.
again, my connections were fiber and high speed. I am not arguing your point but I believe there was an underlying issue in the grandstream hardware specific to the jitter setting and phone processing of the packets in a sip environment. The issue happened even when I called from one extension to another on the same PBX and put the call on hold (completely eliminating my SIP provider). When I ran jitter tests on my connection between me and my PBX I was getting 28-31ms response time with jitter less than 3ms. My Internet is a fiber 1G service and the PBX is in a hosting facility with much larger connections. All my PBXs although Virtual servers have at least 4-8 CPU and 16G ram with ssd drives and only about 40 extensions, I was upgrading everything trying to resolve the audio issues.
The only reason I was using CHAN_SIP in the first place was PJSIP wouldn’t work at my location. Huge issues with my ISP SIGALG and other stuff completely screwed with port 5060. Wasn’t until I moved to a nonstandard port that things started to clear up. I am now in the process of moving everything including my trunks to nonstandard ports with PJSIP. So far everything is working great so I am happy. All issues have gone away with the added benefit of a lot less hack attempts and intrusion detections on a daily basis (went from about 1 a second to 0/hr, when they find my port I’ll just change and reboot all the phones from EPM)