I have an SIP provider that allows me to have incoming calls on a local landline number.
I have tested this number on my server at home, the call ends up on an IVR that is playing some WAV files, and the quality is pretty good.
Then I have tested the number on a server at a client’s place, and the quality is just terrible.
I noticed the audio is bad (robot-style, cut, …) only at the beginning of the WAV file (first two seconds). After the (about) first two seconds (once the WAV file is loaded ?), the quality is good.
It seems not a bandwidth problem (?), because the bandwidth at home and at the client’s place are exactly the same in upload (DL: 5.08 Mbps, UL: 0.46 Mbps).
At the client’s place there is also PSTN/FXO, so I also tested my IVR through PSTN, on the same server, and the quality is good. So the quality is bad only with SIP.
As it is no bandwith problem, and doesn’t seem to be a problem with my server (because through FXO audio is good), what can be the problem ?
I am running out of ideas, thank you for any help!
What does immediately “repeat the sip access” mean ? Could you be more precise ?
I do nothing special, I just call the number … and notice my prompts are bad quality.
Again, what do you mean by access ?
As I said through PSTN I have good quality, and through SIP (no DAHDI…) the quality is bad, whether I call first through PSTN or through SIP, doesn’t matter, with SIP I always have bad quality.
[quote=“david55”]
“Robot-like” is not a well defined term. Could you be a bit more precise?[/quote]
The sound is bad quality and is cut then starts again, then cut, etc. for like two seconds, then I hear well. And when another wav file is played, again for the first two seconds sound quality is very bad. Etc.
Your symptoms sound like a delay to page in code or read in the sound file, as can happen if you try to run Asterisk on a virtual machine, but that would affect the first access to the sound file in a while, rather than the channel technology used to access it.
The only other things I can think of are:
a high jitter. The entity at the end of the SIP connection may start with too small a latency buffer and have to make several increases before it gets one big enough to absorb the amount of jitter present.
Asterisk doesn’t identify timing source changes properly, and some phone react badly to abrupt changes in the time stamps without an associated timing source change. However, I don’t see why there would be a timing source change in this case.
I have some news. I rebooted the computer that hosts the Asterisk server (running on Ubuntu 12.04 Desktop) and the quality is now very good.
It is very strange:
When the server was sending audio through PSTN, the quality was good.
But through SIP, the audio was terrible until I rebooted the computer.