Quality problems (packet loss)

Stewart · Post by **Stewart** » Sun Mar 02, 2008 3:46 pm

I used to say that although MJ has its problems, when it does work, voice quality is always excellent.

Sadly, that seems no longer to be the case. I have experienced numerous calls with choppy voice in both directions. Observations with Wireshark show many lost packets. Unfortunately, I have a wireless Internet connection that is sometimes flaky, so it's difficult to say with certainty what is wrong. However, I have been running some tests where I have two simultaneous calls, one using MJ and one with another VoIP provider. The capture shows packet loss on the MJ call, but not on the other. While it's conceivable that this could be caused by a router or ISP problem, IMO that's extremely unlikely, because it has happened on many calls, yet the opposite condition has not been observed. (It's still true that most MJ calls do not suffer from this trouble.)

I'd like to hear from knowledgeable users who can confirm (or refute) this. What may be the cause, e.g. capacity problem, server line errors, etc? Is there any workaround (switching from Nashville to Newark proxy did not help, even though I observed a corresponding change in media server IP)?

msiam · Post by **msiam** » Sun Mar 02, 2008 4:05 pm

Hi Stewart, Its not that I can help with the remedy in this, I'm not as technical as most on this forum, I will, however, verify that the call Quality has been down hill in the last week.. I was wondering what was going on and now that I see your post, I realize it isn't my imagination.. Hope we can get the problem fixed, I'm sure with all the brilliant folks in this forum it can be..MS

jjj1000 · Post by **jjj1000** » Sun Mar 02, 2008 6:12 pm

Hi All,
I too have had call quality problems pretty much from the beginning of my useage of MJ. Through the process of elimination I have figured out that it seems to be a problem with the connection between my house and the MJ server at Nashville. In the morning call quality is ok. Around 7 pm or so it gets really bad. Lots of missing packets. I followed the directions from other posts and tried connecting to boston since I am in New Hampshire. I do want to point out that using wireshark I identified two servers that I had to redirect to. These were proxy1.boston.talk4free.com and vms1.boston.talk4free.com. Previous posts have referred to proxy1, but not the other one. When I redirect both of these from nashville to boston, my call quality improves. Last night I made a call lasting over an hour, at 7 pm and the call quality for the entire conversation was as good as a verizon connection. This is only one sample, but it is promising. Time will tell.

John

Stewart · Post by **Stewart** » Sun Mar 02, 2008 9:14 pm

Thanks for the post. I set up to use Boston; a one-minute test call showed zero lost packets. I'll do further testing with simultaneous calls via Boston and Nashville to be certain.

jjj1000 wrote:I do want to point out that using wireshark I identified two servers that I had to redirect to.

This sounds strange. When I set up to go via the Boston proxy, it automatically selected the Boston media server. In SIP, for a given proxy and calling parameters, the user has no control of what media server gets used. The SIP proxy selects it and sends the media IP address and port in the SDP (contained in the body of the 183 Progress or 200 OK response). The IP address is numeric; since there is no name, nothing you do with host files or DNS will have any effect. If you redirect at the IP level to another server, you will get dead air, because that server will have no knowledge of your call. My guess is that something else happened to change at the same time as you put in the redirect for vms1.boston .

mufon · Post by **mufon** » Sun Mar 02, 2008 11:42 pm

Stewart wrote:I used to say that although MJ has its problems, when it does work, voice quality is always excellent.

Sadly, that seems no longer to be the case. I have experienced numerous calls with choppy voice in both directions. Observations with Wireshark show many lost packets. Unfortunately, I have a wireless Internet connection that is sometimes flaky, so it's difficult to say with certainty what is wrong. However, I have been running some tests where I have two simultaneous calls, one using MJ and one with another VoIP provider. The capture shows packet loss on the MJ call, but not on the other. While it's conceivable that this could be caused by a router or ISP problem, IMO that's extremely unlikely, because it has happened on many calls, yet the opposite condition has not been observed. (It's still true that most MJ calls do not suffer from this trouble.)

I'd like to hear from knowledgeable users who can confirm (or refute) this. What may be the cause, e.g. capacity problem, server line errors, etc? Is there any workaround (switching from Nashville to Newark proxy did not help, even though I observed a corresponding change in media server IP)?

Wireless in and of itself is a problem because of increased and variable latency. A problem with one voip carrier and not another could be explained by the aggregate latency, the threshold where the max jitter buffer is exceeded for one voip device and not another..

I have several internet connections and on fiber-optics there are no issues whatsoever. On wireless however, it varies. Suffice to say packet latency issues are to blame. Unfortunately because of Jack's rootkit issues we cannot adjust a suitable jitter buffer without hacking.

Stewart · Post by **Stewart** » Mon Mar 03, 2008 1:03 am

mufon wrote:Wireless in and of itself is a problem because of increased and variable latency. A problem with one voip carrier and not another could be explained by the aggregate latency, the threshold where the max jitter buffer is exceeded for one voip device and not another..

I was testing by simply comparing the number of packets lost (those that did not arrive from the Internet, ever) as opposed to discards (those that arrived too late to be played). This is independent of of what device was being used.

mufon wrote:I have several internet connections and on fiber-optics there are no issues whatsoever. On wireless however, it varies. Suffice to say packet latency issues are to blame. Unfortunately because of Jack's rootkit issues we cannot adjust a suitable jitter buffer without hacking.

You could:
1. Record with Wireshark, save to a file, and play it. This effectively gives you an infinite jitter buffer. If the sound is still bad, something else must be wrong.
2. Test with an IP phone or an ATA, where you can play with the jitter buffer settings.
3. Adjust the MJ jitter buffer by changing a registry setting. I believe that you want HKCU\Software\talk4free\USB Softphone\Options\RTP\RtpJitterQueueLength . The unit is packets (20 ms each).

mufon · Post by **mufon** » Mon Mar 03, 2008 2:44 am

There are problems with wireless that you won't see in wireshark even if you sniff the MII of the access point, and there are other transactions handled solely within the radio that never appear on the MII. The RF aspect of wireless contributes substantial overhead, consider only one point and that is every transaction must be acknowledged, and in wait its turn with respect to other clients. These other clients or access points don't even need to be on the same network or access point, but simply transmitting on or near the channel you are on. You can of course help your situation by setting your radio to ignore all traffic except the ap you are connected with, and that may improve overall throughput but could make latency worse by increasing collisions depending on whether or not there are nearby transmitters interfering with your signal. Lots of power cures that I have found. I am a Ham so i am licensed to use up to 150 watts on channels six and below, and I have about 25 watts at the feedpoint of a three foot rotatable dish mounted 30 feet up. Talk about ERP, I keep finding dead birds under my tower, and the storm sirens go off if I point my dish in the right direction. It's a beautiful thing... (those signal levels, not the birds)

Stewart · Post by **Stewart** » Mon Mar 03, 2008 3:39 am

mufon wrote:There are problems with wireless that you won't see ...

What you are saying may all be true, but it's not at all relevant to my situation:
1. My ISP uses Motorola Canopy for the "last mile"; protocol is not at all similar to 802.11 .
2. I have SNMP access to both client and AP; the stats show very few retransmissions and none of the problems that you describe.
3. If there were severe enough interference to cause packets to be completely lost (transmit retries exhausted), many packets would be greatly delayed, but that's not happening.
4. Even if the radio link did lose packets, it would not be "smart" enough to pick on just those from one VoIP provider.
5. Even if packets were somehow selectively lost, e.g. based on destination port number, the affected source would randomly change from test to test.

jlieberman · Post by **jlieberman** » Mon Mar 03, 2008 9:36 am

I am now experiencing very raspy audio on virtually every call. It seems to be associated with the volume at which people are talking: When they talk more softly, the quality is good. When they raise their voices louder, the sound quickly turns very raspy and harsh. It sounds to me like digital overmodulation -- a really grating sound, worse to the ear than analog overmodulation.

The good news is that calls continue to connect lighting fast, and there does not appear to be any latency in the calls. Nor have I suffered any dropped calls.

I just wish MJ would fix the audio quality.

Marcsidnasse · Post by **Marcsidnasse** » Mon Mar 03, 2008 11:20 am

Ya, the sound quality has become very bad in the past week.
Especially for the person at the other end.
I call from Montreal to Dallas on a regular basis.

Cheers!
Marc

Stewart · Post by **Stewart** » Mon Mar 03, 2008 1:48 pm

jlieberman wrote:I am now experiencing very raspy audio on virtually every call. It seems to be associated with the volume at which people are talking: When they talk more softly, the quality is good.

MJ does seem to have excessive gain on the server side, which might cause clipping. But it's not way too high, IMO maybe 3 dB or so. Unless your remote party is really yelling, swallowing the mic, or his carrier also has excessive gain, it seems unlikely that clipping would occur. Capture a call with Wireshark, save the inbound audio to a file and see if it's distorted on playback. If you have audio editing software, you can measure the peak level.

I assume that you already tried adjusting the volume in the MJ softphone.

jlieberman · Post by **jlieberman** » Mon Mar 03, 2008 9:18 pm

Well, today audio quality was "all over the map." Varied from nearly pristine to about as bad an old HAM radio broadcasting from the North Pole. My unofficial estimate is that about 1 out of 3 calls suffer poor quality, and 2 out of 3 are pretty good. I hope that ratio and the overall quality improve soon.

Stewart · Post by **Stewart** » Mon Mar 03, 2008 11:34 pm

I believe that I understand the trouble. It's simply that the Nashville POP site's Internet connection is running out of bandwidth. After noticing slow ping times, I tried some tracing. The XO web site lets you ping and trace from their core routers; here are some results (all taken from Atlanta to rtr.nashville.talk4free.com):

Code: Select all

trace route 67.90.152.126 
 
 Type escape sequence to abort.
 Tracing the route to 126.64/26.152.90.67.in-addr.arpa (67.90.152.126)
 
   1 ge5-3-0d4.rar2.atlanta-ga.us.xo.net (65.106.2.33) 0 msec 4 msec 0 msec
   2 p4-0-0.MAR2.Nashville-TN.us.xo.net (65.106.4.50) 8 msec 12 msec 12 msec
   3 p15-0.CHR1.Nashville-TN.us.xo.net (207.88.85.110) 8 msec 8 msec 12 msec
   4 ip65-46-196-26.z196-46-65.customer.algx.net (65.46.196.26) 204 msec  
(I believe that the IP shown for hop 4 is the WAN address of the MJ router.)

ping 67.90.152.126 
 
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 67.90.152.126, timeout is 2 seconds:
 !!!!.
 Success rate is 80 percent (4/5), round-trip min/avg/max = 200/202/204 ms
(Above ping was done during heavy traffic this morning.)

ping 67.90.152.126 
 
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 67.90.152.126, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/16 ms
(Above ping done about an hour later, when traffic had become somewhat lighter.)

saxman · Post by **saxman** » Tue Mar 04, 2008 5:57 pm

Well, it was about a week or so back that Dan the Man said he was lowering the bandwidth which is supposed to give better audio quality. He said it would be lowered to the same level as it is now when a person calls from one MJ to another MJ which is supposed to be a really clear call. He said it would really improve the sound by doing this. He didn't say when this would happen. My calls all got real good since yesterday when I added the Hawking HBB1 Broadband Booster and a powered network switch.. The audio is great right now. It does still mess up a little while doing big downloads though. I still haven't got around that.

dukeomaha · Post by **dukeomaha** » Tue Mar 04, 2008 6:12 pm

saxman wrote:...He didn't say when this would happen...

"Soon" is magicjack's magic word!

saxman · Post by **saxman** » Tue Mar 04, 2008 6:43 pm

"Soon" is magicjack's magic word!--lol-I hear ya-although, I really can't complain about the one on one tech support help they gave me this last week.Dan had one of his guys work with me via email to get my audio sounding better. He was good and friendly and he stayed with it and said to email him again if it goes South. So, they are really trying hard to get the kinks ironed out so they can sell millions upon millions of these little blue money saving matchboxes. They even had a tv commercial on my set the other night. It was around 3 am-the cheap hour but hey, thats good. Means they plan on being around a while. Least until they get the boatload of matchboxes sold-lol

magicJack and magicJack Plus Support, Reviews, FAQs and Tricks

Quality problems (packet loss)

Quality problems (packet loss)

Re: Quality problems (packet loss)

Re: Quality problems (packet loss)