2

Currently I have a system that makes use of FreeSWITCH for outbound calls via SIP External with flowroute and works well, but some users complain about the quality of the call. The system is running the call using a lua script, in which you create two sessions (one for each user), and which are within the same script bridge and record the call, once both have established a connection. G711 codec is used.

Users who complain say that sometimes the audio is very low or stutters. The strange thing is that when you listen to recordings of these calls both people listen very well.

Have been testing the user and normally is poorly listening of the leg 2 of the call. Because of this and the characteristics of the system that I mention, I suspect that when bridging the communication is that the audio fails, or low quality. But I have not found anything conclusive.

I write to ask if anyone knows why this behavior can be given during calls, and because it is perceived in his recordings.

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
Sansa
  • 21
  • 1
  • 2
  • Is the recording machinery local to the switch? – NickW Apr 10 '13 at 14:57
  • The call quality could be wrong but your recording is of good quality and not appreciate interference from speaking the users. No that's your question, but I think regardless of whether it is local or not, this does not lead to any conclusion. – Sansa Apr 10 '13 at 15:55
  • Different things can cause interference, if the recording equipment is on the rack next to the switch, there isn't likely to be much in terms of latency or jitter.. whereas the client has a network bottleneck(too much downloading, or uploading). Local recording would only find problems in codecs. – NickW Apr 10 '13 at 15:58
  • As I mentioned in the question, I make the recording directly on the lua script and it does not use any external machine FreeSWITCH and storage occurs locally. From what I read in what you say, then the problem would be in the codec. Any suggestions of what I should check? – Sansa Apr 10 '13 at 16:17
  • No, I said that if the recording was local, and you heard problems (you say it sounds good though) then the issue would probably be the codec. It's quite probable that the problem is the network on the way to the client as suggested by Stanislav, possibly something that is out of your control, like QOs. Do you have a high volume of calls when the clients complain of problems? – NickW Apr 10 '13 at 16:33

2 Answers2

1

If the recording is good, you know that packages from both devices made it to freeswitch. I am not sure which way the recording was executed but there is a good chance this gives you a hint to that both packages made it in time to the server as well. (These things could be proven with a tcpdump of all upd packages and wireshark, it was a good suggestion to capture traffic on the server to examine it!) From my extensive experience with VoIP this sounds however like a problem with ingress bandwidth on the site of the person who is experiencing the bad audio, sometimes problems like these also show up due to not correctly set (or on the way discarded) QOS flags. Make sure all devices and freeswitch use EF as QOS setting for RTP. Using wireshark you can also check if flags get dropped by your ISP. If they do, there is usually little you can do about it unless you have a business accounts that claims to support QOS, in which case you should complain to them.

Frank Waller
  • 53
  • 6
0

this could be the network problem on the way to the user. Also, the voice quality depends on the type of host which is running FreeSWITCH. Is it a physical machine or a VM? If virtualized, then which virtualization technology?

Also, it makes sense to collect a packet capture at the user side and analyze in Wireshark.

Stanislav Sinyagin
  • 263
  • 1
  • 8
  • The server is virtualized via Rackspace. On their website they say they use Vmware, but do not speak much of the internal technology they use. I leave the link: http://www.rackspace.com/cloud/private/managed_virtualization/ As to what you mention to capture packets, I have reviewed with tcmpdump and find nothing abnormal. He also checked the bandwidth usage with iptraf and no more than 30 kbps, during calls. Should review something specifically? – Sansa Apr 10 '13 at 16:05
  • VmWare is not the greatest FreeSWITCH environment, because FreeSWITCH relies on the hardware clock, especially in conferences and complex bridging scenarios. I would suggest to try a XEN or KVM hosting. My voice server runs under XEN, and I had never any problems with the quality (hosted at softronics.ch) – Stanislav Sinyagin Apr 10 '13 at 22:37