Hi all, recently our sip trunk getting poor voice quality when many staff using this trunk to call out. during the call, sometime will having silence from customer. I attach a snapshot that show max jitter go up to 128.25ms. May I know this which end are having issue?
High traffic and poor audio can sometimes be corrected by setting qos/tos on your network/router asterisk itself can’t do that.
may I know which site should do the QOS/TOS setting on network router? I having 2 sip trunk provider, only 1 sip provider trunk getting this issue. I reported this issue for them, the answer getting from them is “other customer not getting this kind of issue”.
There is no site to do that, you need to do that on your own edge network device, (the thing that connects to the internet) but if only one VSP has a problem, then it is likely not a VSP you should use.
I can’t make much sense of this screenshot, because it shows the first packets sent by the provider and there are often anomalies during the first few hundred milliseconds, e.g. jitter buffer adjustment.
Assuming that you still have the .pcap file, please post a shot showing the long gap (put packet number 43474 near the middle of the screen).
Please correct any of these assumptions that are wrong: You and the provider are both in Singapore. The capture was taken on the PBX and without any filters. There were 4 calls in progress at the time.
Also, please post: internet connection contract speed up and down? Speedtest result up and down? Internet connection type (fiber, cable, vdsl, etc.)? Router/firewall make/model? PBX hardware platform? If virtual, post details. If you have a DID with this provider, do you also have trouble on incoming calls?
my provider server base at Singapore and my pabx are located at Malaysia. during the process I capture the pcap file is around 5 ppl making the call. our internet connection type are using fibre and the router are provide by ISP. don’t have firewall. we are making outbound call only and does not require DID. our PBX is hardware platform.
So let’s clear some things up. Fiber does not make an Internet connection flawless, it’s a transport/delivery method just like copper or coax. You are showing a high latency for your connection. This can impact your audio quality. Now most codecs like g711 can handle a good chunk of packet loss, even upwards of 30% and you can still have a decent call.
That being said the Jitter is a completely different matter. That has a much lower tolerance, around 30%, which means that once you start getting upwards of 10-20% of Jitter you’re going to start seeing issues, get to 30% you are definitely going to see issues. Over that the call quality is just going to be awful and unusable.
Bottom line is, a crappy Internet connection is a crappy Internet connection. Your is just over fiber vs coax or copper.
from this analysis, your conclusion is not voice provider connectivity issue?
Yes, my conclusion is that your Internet that is supplied by your ISP is performing poorly. Not really a voice provider issue.
What codecs are you using with this provider that is having a problem?
Unfortunately, the second screenshot is not useful, because it is sorted by jitter. Please click on Packet to sort by increasing packet number (as it was in the first screenshot), move the scrollbar so packet number 43474 is near the middle of the screen, then take a screenshot. What we are looking for is the rate of packet flow around that time. For example, if the rate of packet flow during the gap is otherwise normal (the other calls had normal audio), this is almost certainly a provider issue, because it’s very unlikely that a problem with your ISP or network would lose only the interspersed packets from one of five calls. But if the rate drops about in half, that implies that all your agents heard silence at the same time, which could well be a network issue.
Or, if it’s ok with you, export only the RTP from the .pcap file, make a .tgz file and post it here. However, while the RTP won’t contain any personal info such as IP addresses (other than the provider’s), account numbers, phone numbers, etc., you still shouldn’t post it if you are concerned about the contents of the conversations or the voices of the participants.
my codec is using G729
Oh man, G729 has ZERO tolerance for poor Internet connections. High latency and jitter is going to cause G729 based calls to sound just horrible and probably make the call impossible to have.
I agree with @BlazeStudios that you shouldn’t be using G.729, but don’t switch to alaw until you have resolved your main problem.
Look at the .pcap starting at packet 8758. There were 4 calls in progress and RTP for all 4 stopped coming in at the same time. Incoming traffic did not resume until packet 8934, more than a second later. But when they did resume, the buffered packets for a given call were all bunched together. IMO it’s very unlikely that any buffering by your ISP or an intermediate carrier could cause that, so I am reasonably sure it’s a provider problem.
To further confirm this hypothesis, run a call with your other provider, simultaneous with your normal workflow. If RTP from this call continues to flow normally during the caps, that’s pretty convincing.
A good source for these kinds of tests is
If Singapore is local with your alternate provider, you can use iNum. Call +6531581212 (iNum gateway, see http://www.inum.net/what-is-inum-2/local-access-numbers/ ). At the “welcome to iNum” prompt, dial 001196512# and you’ll be connected to TheTestCall.
im am new on Wireshark analysis, may I know how to you saw the call stop coming in at the same time?
Packets 8745, 8746, 8748 and 8749 are from four different calls (port numbers are different).
Packets 8753, 8754, 8756 and 8757 are the next packets from the same four calls. The interval between packets for the same call is ~20 milliseconds, as expected.
After that, there is no incoming traffic for more than one second. However, traffic (that was received from extensions) continues to flow out to the trunks. This indicates (with reasonable certainty) that the the LAN is working properly and the PBX is not overloaded.
Based on the way traffic resumed, I feel that a provider problem is likely, though it’s conceivable that your router, ISP or an intermediate carrier buffered the four streams separately. If a test with your alternate provider shows that their RTP stops flowing at the same time, we can investigate the network issue further.
BTW, when you reach TheTestCall (by whatever means), when you hear the first “record your test message then press pound”, press #, then when you hear the main menu, press 4 for hold music. The music plays for about 10 minutes, which should be long enough to complete your test.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.