MJ update 2.0.4, pending ACK, dropped calls, Linksys, VOIP..

[speaker2112]

Warning, long post ahead, but worth reading if you have problems which started since the October 2010 MagicJack update. I'm adding a poll too so we can hopefully see how many people have been affected by the update.

VOIP call problems (e.g. Skype, Comcast) since recent 2.0.4 update in October 2010. Pending ACKs, echoes & dropped calls. Using a Linksys WRT54GS (v2.1) router which was working fine with MJ prior to the recent MJ update!


Starting in October when the last MJ update was distributed I began noticing call problems, most notably when I placed or received calls to family members who use Comcast phone service (VOIP) and also when receiving Skype calls to my Magicjack. The poor quality of calls and disconnects seem to be primarily with incoming calls. I will refer to these calls as "VOIP calls". Prior to the MJ update I was able to make and receive stable calls just about all the time to and from all number/line types.

Now it seems I can only place and receive stable calls to non-VOIP parties, so generally standard phone line and cell phone number calls are acceptable quality.

The quality problems with VOIP calls manifest in 3 ways. (1) First, the other party will hear voice echoes on their side but I will not. However, I will hear occasional audio artifacts (e.g. short, slight echoes) which the other party will also hear. (2) VOIP calls will often result in "Pending ACK" messages in the MJ softphone window and call quality will be choppy. Note that I never saw this pending ack message prior to the recent MJ update and I realize this message is referring to the TCP acknowledgement messages which are being waited on. (3) VOIP calls will disconnect after approximately 32 or 33 seconds.


I've read a substantial amount of information on this forum about these types of problems and have made some corrective attempts at improvement but so far am still suffering from the problems mentioned above. Some of the threads that discuss these issues which I've checked with hopefulness are:
http://www.phoneservicesupport.com/here ... t9456.html
http://www.phoneservicesupport.com/pend ... t9722.html
http://www.phoneservicesupport.com/call ... t5991.html
http://www.phoneservicesupport.com/inco ... t4448.html

My rig for MJ calls consists of a Windows 7 x64 workstation running MJ 2.04 connected to Comcast internet through a Linksys WRT54GS v2.1 router. (Captured packets indicate the MJ servers are running version 2.05.xx). I am aware that many people have had VOIP problems with certain Linksys routers, and I'm certainly not denying there may be bugs with the Linksys firmware, however, as I mentioned above, all my calls were relatively stable up until the most recent MJ update in October so it's hard for me to blame my router as the sole cause of the problem.

Since it was suggested that upgrading the firmware on the Linksys could help I did so and upgraded from v4.50.6 to v4.71.4 which brought no improvement to the MJ problem. I then looked into alternative firmware options and decided to try Tomato or DD-WRT, but Tomato first only because it seems to be under current development. I was hopeful the Tomato firmware (v1.28) would remedy any firmware issues with the stock Cisco-Linksys firmware, but unfortunately the MJ problems persisted. Now I am planning to try the DD-WRT firmware but cannot do so for a day or two so wanted to post this thread in the meantime to get some feedback. In fact, I would like to get MJ running directly on the router loaded with DD-WRT using this thread as my guide... http://www.phoneservicesupport.com/ddwr ... t6913.html - if it's possible to connect the MJ to the Linksys WRT54TGS with a USB->RJ45 connector as the Linksys does not have a USB port.

In any case, thinking back to when the original problems started a few weeks ago I realize that I had changed nothing leading up to the start of the call problems. The only change at that time was the MJ update to v2.0.4. Therefore, even if the firmware updates are advantageous in certain ways, the initial Linksys firmware WAS WORKING fine for 99% of calls prior to the MJ update. Therefore, I have to assume that either the MJ software is causing the problem or now exposing a problem with the Linksys which was previously not causing an issue. Otherwise, the problem could be due to the MJ infrastructure itself in terms of any changes they have made on the servers or with their networking infrastructure. Unfortunately, I would not have any control over the latter items, though I may be able to resolve problems introduced by the MJ client software.

Since the dropped calls and pending ACKs have started happening with only VOIP calls (e.g. Comcast VOIP, Skype, etc..), it seems that something on the protocol side has changed in terms of MJ compatibility with other VOIP providers. Is anyone else noticing this???

I would appreciate hearing any additional info on this topic and experiences or insights others are having related to the recent MJ update and call quality, specifically calls to and from other VOIP providers. Thanks!

[crackerjack]

Forget about using the MJ in any way other than how it was designed.
Try this VOIP quality test voiptest.8x8.com (requires JAVA)
try forcing the latest upgrade direct from MJ site
try changing the proxy your MJ is using. Search these forums for proper DOS CLI commands
get a powered USB hub

[tsmith]

+1 on what crackerjack said.

[speaker2112]

Forget about using the MJ in any way other than how it was designed.
Try this VOIP quality test voiptest.8x8.com (requires JAVA)
try forcing the latest upgrade direct from MJ site
try changing the proxy your MJ is using. Search these forums for proper DOS CLI commands
get a powered USB hub

I am using the MJ how it was designed, running on Windows! I was only considering the option of running it direct through the router using DD-WRT, but have not even come close to trying that.

I'll consider trying the VOIP test but currently do not have Java installed as I hate having Java apps run in my browser. In any case, I am able to make and receive calls to normal landlines and cellphones fine, so doesn't that prove my internet connection is VOIP worthy?

I forgot to mention this in my first post, but after reading the Wiki for instructions I did change my proxy several times without any improvement.

My magicJack is plugged into a USB port on my PCI-USB hub. This should be powered by definition, correct? The PCI card gets power directly from the motherboard.

[bitstopjoe]

Forget about using the MJ in any way other than how it was designed.
Try this VOIP quality test voiptest.8x8.com (requires JAVA)
try forcing the latest upgrade direct from MJ site
try changing the proxy your MJ is using. Search these forums for proper DOS CLI commands
get a powered USB hub

I am using the MJ how it was designed, running on Windows! I was only considering the option of running it direct through the router using DD-WRT, but have not even come close to trying that.

I'll consider trying the VOIP test but currently do not have Java installed as I hate having Java apps run in my browser. In any case, I am able to make and receive calls to normal landlines and cellphones fine, so doesn't that prove my internet connection is VOIP worthy?

I forgot to mention this in my first post, but after reading the Wiki for instructions I did change my proxy several times without any improvement.

My magicJack is plugged into a USB port on my PCI-USB hub. This should be powered by definition, correct? The PCI card gets power directly from the motherboard.

YES, but.. If there is not enough power because of multi USB devices you need a POWERED usb hub. One that gets its OWN power via plugging it into a wall outlet.. Some USB devices need more power than others ( MJ included). It is also a good thing to plug your MJ into a REAR usb port as it is a direct connection to the Motherboard as opposed to a front port which is really nothing more than an unpowered usb hub.
Oh yeah throw away the small extension cable which came with the MJ.

[speaker2112]

HMM... I understand the suggestion Joe, but the magicJack is the ONLY device plugged into the USB-PCI hub.

More importantly though, all calls were fine with this EXACT HARDWARE SETUP prior to the MJ 2.0.4 update in October. I don't see why the USB power draw would decrease without any hardware additions.

Will test again tomorrow when I can call my family on their VOIP line...

[bitstopjoe]

HMM... I understand the suggestion Joe, but the magicJack is the ONLY device plugged into the USB-PCI hub.

More importantly though, all calls were fine with this EXACT HARDWARE SETUP prior to the MJ 2.0.4 update in October. I don't see why the USB power draw would decrease without any hardware additions.

Will test again tomorrow when I can call my family on their VOIP line...

One reason is the MJ 2.0 update was a BIG update using more resources. How that can affect the USB port?? Beats me, BUT as PCs age it can affect the USB ports. I had a situation last year where I was not able to write to a USB thumb drive, but I could read from it. I never had problems writing to it before. So I did something drastic and went into my device manager, usb section and deleted everything ( note delete your usb mouse setting last After I did all that and rebooted all my USB drivers were re-installed and I was able again to write with no problems to my thumb drive.
If I were you the first thing I would try is to take your MJ out of the hub and plug it into a rear USB port ( sans extension cable) and see what happens. I mean it can't hurt to try...

[tomquinnta]

I posted a similar situation yesterday. I experience dropped calls and garbage on both ends prior to being dropped. Only on outbound calls and only a small number of calls. I have had numbers I call have this issue. Yet they can call me and we are OK?

Sounds like it is on the other end of the magic jack - the reciever side for me.

Any ides?

Thanks

Tom

[conniemadagain]

Any ides?

Thanks

Tom

Nettalk?

[speaker2112]

I posted a similar situation yesterday. I experience dropped calls and garbage on both ends prior to being dropped. Only on outbound calls and only a small number of calls. I have had numbers I call have this issue. Yet they can call me and we are OK?

Sounds like it is on the other end of the magic jack - the reciever side for me.

Any ides?

Thanks

Tom

In my case I am mainly having trouble making calls to a Comcast VOIP phone number which generates a lot of pending ACK messages and then disconnects after 33 seconds. During testing receiving calls from that same number is typically a clear call and does not disconnect. I am also having trouble connecting to a number which I know is valid, but I get a message saying the number is not in service.

I believe there are some VOIP incompatibilities happening in these cases and I'm in the process of capturing and analyzing network traffic to see exactly what is happening...

[speaker2112]

I have been doing some testing and have found that the "pending ACK" issue only occurs on outgoing calls, and consistently when I call my Mom, who has VOIP phone service through Comcast.

I get the pending ACK problem when my system is connected directly to my cable modem completely bypassing my Linksys-Cisco WRT54GS and with the Windows firewall turned OFF. Thus, it is quite clear this ACK problem is not due to the Linksys as previously suspected!

While capturing the traffic from those calls (both incoming and outgoing) and comparing them to other calls I have found one interesting consistency - all outgoing calls from my magicjack to my Mom show that a provider called Neutral Tandem (http://www.neutraltandem.com/) is somehow involved. One of their IPs, namely 74.120.93.68, consistently shows up in some of the SIP packets for calls from magicjack -> Comcast.

I need to do further analysis to understand the structure of the SIP protocol, but my guess right now is that as part of the October software upgrade (when this problem started for me), magicJack/YMax started some sort of peering agreement with Neutral Tandem for routing some calls. From a cursory review of the packet capture it looks like there may be some SIP protocol incompatibilities between two systems. I need to look into this further to better understand exactly what's going on though...

Hopefully I will be able to learn more about what is going on soon, but if anyone has some SIP/telephony experience in this area who could help shed some light, feel free to chime in.