MagicJack Proxy Issue

[IanNoga]

Hello, I have been a fan of magicJack for almost two years now. I have been experiencing a problem with the magicJack in my area for quite some time and I have decided to shed some light on it in order to see if others have similar problems or can even help me resolve this issue. I have contacted the magicJack tech support, but they were of no help.

When I use my magicJack that has a 954 area code to dial a bellsouth (at&t) pstn land line phone that also has a 954 area code there is a noticeable echo. When I use my magicJack that has a 585 area code to dial the same bellsouth (at&t) pstn land line phone there is not an echo. I have tried this dozens of times and it appears that a call from a 954 magicJack to a 954 pstn landline phone through bellsouth (at&t) produces an echo. In order to conclude this, my friends and I gathered 3 magicJacks, 3 computers, 3 at&t 954 landline phone numbers and 3 different internet connections. When we dialed the pstn numbers from the 954 magicJack, there was a noticeable echo, but when we switched the area code of the magicJack to the New York 585 area code, there was not an echo at all when the 954 pstn number was dialed.

Since the 585 area code magicJack does not produce an echo, there is most likely a routing issue with the 954 area codes and 954 bellsouth (at&t) pstn numbers because the 585 is on a different proxy that does not produce an echo. Since the Newyork proxy works perfectly and does not produce an echo then there has to be an issue somewhere in the routing with the Miami proxy. If it is a server error that could be fixed remotely or a hardware problem with the network, I would not know.

Thus, there is something among magicjack VOIP calls from their 954 proxy to at&t 954 landline phones that is producing an echo. I do know there is a problem with the echo cancellation somewhere between these connections and it is quite big because every magicjack I come in contact with that has a 954 number that tries to dial a 954 at&t landline phone produces an echo regardless of internet connection, computer, firewalls, routers, modems, etc. The echo only goes away when I use a different magicJack proxy such as a 585 NewYork one. Does anyone have any similar problems or solutions to this problem?

I forgot to add: Whenever I dial a cell phone or another magicJack number from my magicJack (regardless of area code) there is not an echo at all.

Thanks

[davrow]

This is a well documented phenomenon - dialing same area code causes echo. Seems to especially affect New York.

It is an issue with the phone company servers, unfortunately.

You can get the echo to go away with the *67 trick, but no one has found any other resolution.

Thanks to other posts I found on this forum I tried the *67 "trick" to see if I could get rid of the horrible echo. Sure enough, it did!!! I'm a happy camper (no thanks to MJ tech support). If I dial 718-xxx-xxxx I still get an echo (even if I just call a home depot that has an auto-attendant pick up the phone - if I talk to the answering machine I hear an echo). But if I dial *677*18xxx-xxxx there is NO echo

See this thread: http://www.phoneservicesupport.com/echo-t974.html

[jaqie]

It is an issue with the phone company servers, unfortunately.

False. if this were true it would do the same for POTS and also my vonage. it does not. this is a classic case of magicjack corp pointing fingers.
It is an issue with the magicjack CLEC, PTSN, POP, or such in that area.

[davrow]

Okay, but I think you are getting nitpicky.

It is a problem with how magicJack ("our" phone company) hands off calls. But it is a problem between magicJack and the "real" phone company.

In neither case can we do anything more than complain.

Better?

[IanNoga]

I tried the *67 trick, but it did not work. I still heard an echo when I called the pstn line from my magicJack.

[az2008]

I tried the *67 trick, but it did not work. I still heard an echo when I called the pstn line from my magicJack.

When did you get your MJ device(s)? I've read that there is a TigerJet echo-canceling tool people used for units prior to May 2008. But, a new rev of the device has it built in.

My unit is from June. I occasionally hear some echo (when calling local numbers) for the first few of my words. Then it goes away.

If your unit is older, maybe someone can explain how to determine which rev you have. The echo-canceling software was removed for download by TigerJet. But, it's available from here: http://www.dslreports.com/forum/r214335 ... er-Utility

Mark

[IanNoga]

That is interesting, I never heard of that before. But, unfortunately I got my unit in July 2008 so that does not solve the issue. I have tested this on more then 3 magicJacks as well. (All bought recently.) I figure there is something wrong with magicJack's echo cancellation settings somewhere in some sort of server where the miami, FL. proxy routes to. I don't think there is really a way to change the proxy anymore either. (A change in proxy solves my problem, but the only way to do this is change my area code to a NewYork 585, but I would like to keep the 954 area code and use this 585 NewYork proxy.) You use to be able to edit the hosts file to use a different proxy, but now it does not seem to work.

[az2008]

I figure there is something wrong with magicJack's echo cancellation settings somewhere in some sort of server where the miami, FL. proxy routes to.

If you really believe it's an MJ server, the only thing you can do is use MJ dead chat and be persistent that you believe the problem needs to be escalated to an engineer. Go through all their diagnostic attempts (reading from a script), but remain persistent that after all their diagnostics fail, that you need to be escalated.

It could take a lot of time. But, I think if you're friendly, patient, explain your own diagnostic activities, and make it clear that you're trying to help MJ fix a problem which you believe is affecting others, I think you can get it elevated.

You use to be able to edit the hosts file to use a different proxy, but now it does not seem to work.

You seem like an industrious young man. I think it's possible to use iptables/ipchains (on a unix-based router like Tomato or DD-WRT) to change all packets destined for one address to another. The problem is, there's a very steep learning curve associated with iptables/ipchains. If you're really into debugging/solving your problem, you could spend a few hours learning iptables/ipchains, and how to add a rule to the router's firewall.

I bet it's just a one-line rule (like preroute and the -DEST parm). I spent 2-3 hours looking at it. I gained a basic understanding of the tables and stages that can be chained. But, it was going to take a few more hours to figure out how to change outbound packets. (Most documentation, tutorials, etc., focus on inbound packets because iptables is primarily for writing firewalls).

If you could find an expert on a forum related to iptables, they could probably tell you the rule without much effort.

Mark

[IanNoga]

I know my way around the magicJack dead chat. I got the higher level of support and had them forward my issue to the engineers. It was odd though, I asked for a ticket number and I think they made it up. When I tried to check on my ticket, I had to explain the problem again and I was told I would receive an e-mail from the engineers.

The third time I checked on the problem, I had to re-explain it once again and by that time it was just overwhelming obvious that these people just forward these problems via e-mail to an address that elicits no form of response. It does make for a funny conversation with my friends and I. i.e. “Unplug your magicJack and plug it back in.”

I have heard the term "Black Box" and I believe it is a perfect term for this situation.

I didn't expect much with the technical support anyways; I just wanted the issue to be forwarded to the engineers. I did this November 1st through November 10th and I hope that someone, somewhere, that works for magicJack has read up on this proxy issue.

As for IP tables, I have looked into this before and I believe (hope) I could do it. The problem is that I can deal with the echo. I barely call pstn landline phones anyways. I am interested in this because the members of my family and some of my friends are not computer savy at all nor do they have anything more then at&t DSL or comcast cable with a modem and nothing else.

It would be nice for them to have wireless though…I wouldn't buy them the $50.00 linksys routers, they would have to pay for that themselves.

Anyways, It does seem like the IP tables would fix everything though. I was wondering if magicJack will revert back to being able to edit the hosts file in order to change proxies because the IP table aspect makes things very insecure for magicJack users. Normally, I would just buy a router and test the IP table aspect, but it is very confusing and time consuming. I fear that I will not be able to do it.

[az2008]

As for IP tables, I have looked into this before and I believe (hope) I could do it.

If you could figure out how to use iptables to change outgoing packets to a different address it would be a big help to a lot of MJ users. You'd be famous.

Mark

[IanNoga]

Alright, I have attempted to change the IP tables on my linksys running dd-wrt. I wanted to IP forward from the miami IP to the NewYork IP. I entered the command line:

iptables -I FORWARD -p all -s 216.234.79.8 -d 67.106.135.70

My test to see if this works is a simple ping test. When I ping the 216*, I get a ping of around 100. When I ping the 67*, I get a ping of around 40. The 216* is the Miami and the 67* is New York. Thus, when I entered this command, I tried to ping the 216*, but I still got a ping of around 100.

What am I doing wrong? Is there anything wrong with the command line? Should it be UDP not all?

Side Note: When I did a trace route on the 216*, I noticed that xo.net is where the ping shoots up to around 100. There is something with this backbone provider that is creating this high ping and it may be the cause of some of the choppiness in the Miami proxy and might even be causing this echo.

[IanNoga]

This is suppose to be an easy command. I just can't get it. Anyone have a guess?

[IanNoga]

If you run a line quality test through DSL Reports from the magicJack's Miami IP (216*), you will notice that something happens from the west coast going to the east coast and vice versa that results in 100% packet loss. The ping shoots up from around 50 to over 100.

If we change the proxy through IP tables then we may be able to obtain high call quality and to lose that annoying echo. Over the last couple of weeks, call quality appears to diminish greatly during prime time. Hopefully a change in the proxy will fix this as well.

As for the IP Tables, I am throwing in the towel. I have no idea what I am doing wrong. It seems like it is suppose to be a simple command, but it could be a command line a page long for all I know. If anyone has any advice or knowledge for IP tables, I would greatly appreciate your help. Thanks for everyone's input!

[hsweiss]

I've been experiencing the echo problem (someone quoted from one of my previous posts about using *67). I have a MJ in the NYC area code (718) and all calls since July have had terrible echo. Prior to that it was only once in a while. I've had numerous 'chats' with the tech dead heads - always resulting in a "we will report this problem to the engineers" and with a promise of a fix in a day, week, etc. I've also complained to "dan the inventor" and got a reply a few times from his tech support guys but no fix. The last couple of times I've sent email to "dan the inventor" there has been 0 replies. I've tried the TJ echo cancellation - no difference at all. I've switched computers with no difference at all. Just like others have said, calls within the area code suck. All other calls sound great w/no problems. I really wanted to have a NYC local number but I'm almost ready to switch to another area code to get rid of the horrible echo.

I've also investigated switching to another proxy via the change in the hosts file. At least in my case, it did not work and then when I reverted to the original proxy by removing the change to the hosts file, MJ would not connect to the proxy. Tech support had to "refresh" my account to make it work again. Seems like they've instituted single proxy authentication.

The shining light, at least in my case, is that the *677*18-xxx-xxxx dialing method usually works and results in no echo. It has resulted in longer connect times and often reduced volume on the resulting call. Also, a few nights ago, when dialing with *677*18 the call would drop back to a dialtone after a long wait. When dialing w/o *677* (just 718-xxx-xxxx) the call immediately went through, volume was high, but echo was bad.

Sigh.... but what can you expect for $20/year?

[az2008]

I've also investigated switching to another proxy via the change in the hosts file.

The last time I tried, the hosts file didn't work. MJ was using the IP address of the proxy, not the hostname. So, it never did a DNS lookup (apparently never causing Windows to look in the host file to possibly resolve an IP address to another IP address, if that's even supposed to work).

Mark

[IanNoga]

Yes, that is why the re-routing to a different proxy has to be done via IP tables. The hosts file no longer works.

[laserjobs]

Don't tell me magicJack is using IPs again for the proxy. When mj first started they did this and when the proxy went tits up then service was unavailable. At least with a host name the proxy can be redirected to another proxy if there is a problem.

Don't these guys learn from previous experience?

[az2008]

Don't these guys learn from previous experience?

If they need the ability to switch proxies, it should be done on their end so they can cause it to happen seemlessly, not expecting customers to jack up their own host file (and never change it back, and causing confusion when a customer needs support).

If it has to be done by the customer, then the proxy should be selectable from the softphone menu.

A host file is not the solution to the general problem you referred to. But, it was useful for the tinkerers.

Mark

[laserjobs]

Don't these guys learn from previous experience?

If they need the ability to switch proxies, it should be done on their end so they can cause it to happen seemlessly, not expecting customers to jack up their own host file (and never change it back, and causing confusion when a customer needs support).

If it has to be done by the customer, then the proxy should be selectable from the softphone menu.

A host file is not the solution to the general problem you referred to. But, it was useful for the tinkerers.

Mark

It has nothing to do about users being able to change their host files, it is about redundancy where magicJack can change the DNS server to point to an operating proxy.

If you were an original MJ user you would know that the problem occurred where everyone was down. If MJ was using DNS instead of an IP they could have got everyoen back up within the hour by changing the DNS server to another working proxy.

[az2008]

It has nothing to do about users being able to change their host files, it is about redundancy where magicJack can change the DNS server to point to an operating proxy.

Thanks, I understand now. I agree. That would be useful. I thought you were talking about the users' ability to change to a different server by faking out MJ via the host file.

It seems like the softphone stores the ip address in the profile.db. I don't know when it got it, or if it has some capability to retrieve a new IP address if connecting to the proxy fails.

It's strange because I saw it use a hostname (apparently stored in the profile.db) a month or so ago. A couple weeks ago I tried it again and saw it use an IP address. I don't recall doing anything between those experiences to cause my softphone to go through the registration process. So, during normal operation it must've been given a new address to store in the profile.db. If that's true, then conceivably they can push a new address if the proxy is down(?).

Mark

[MagicHack]

It has nothing to do about users being able to change their host files, it is about redundancy where magicJack can change the DNS server to point to an operating proxy.

Thanks, I understand now. I agree. That would be useful. I thought you were talking about the users' ability to change to a different server by faking out MJ via the host file.

It seems like the softphone stores the ip address in the profile.db. I don't know when it got it, or if it has some capability to retrieve a new IP address if connecting to the proxy fails.

It's strange because I saw it use a hostname (apparently stored in the profile.db) a month or so ago. A couple weeks ago I tried it again and saw it use an IP address. I don't recall doing anything between those experiences to cause my softphone to go through the registration process. So, during normal operation it must've been given a new address to store in the profile.db. If that's true, then conceivably they can push a new address if the proxy is down(?).

Mark

The profile.db only contains the following (encrypted) information:

Code: Select all

CustomField19 = <YOUR PHONE NUMBER>
SavePersonalData = 1
FileName = ""
Type = SIPProxy
Name = magicJack
CustomField0 = <YOUR EMAIL ADDRESS>
CustomField2 = <YOUR PASSWORD>

It does not contain any host information.

The proxy information is returned (again, encrypted) from the provisioning server. magicJack used to return host names, but now it returns something like:

Code: Select all

[SIP 2.0]
ProxyUserName=EYOURNUMBER
ProxyUserPassword=YOURPASSWORD
SIPCallerID=EYOURNUMBER
RegisterOnProxy=1
SIPRegistrationAcceptResponseWithoutContact=1
SIPVoiceMailAddress=YOURNUMBER
EnableTelephoneEvents=1
SIPProxyURI="sip:216.234.64.8:5070;transport=udp,
sip:67.108.236.70:5070;transport=udp,
sip:67.88.218.6:5070;transport=udp,
sip:64.0.147.6:5070;transport=udp,
sip:66.104.96.198:5070;transport=udp,
sip:67.107.71.134:5070;transport=udp,
sip:67.88.11.6:5070;transport=udp,
sip:71.5.113.6:5070;transport=udp,
sip:67.91.177.70:5070;transport=udp,
sip:216.234.78.8:5070;transport=udp,
sip:67.91.233.134:5070;transport=udp,
sip:67.107.82.70:5070;transport=udp,
sip:67.90.16.6:5070;transport=udp,
sip:64.1.213.70:5070;transport=udp,
sip:67.109.32.70:5070;transport=udp,
sip:67.88.10.198:5070;transport=udp,
sip:216.234.79.8:5070;transport=udp,
sip:67.88.183.70:5070;transport=udp,
sip:67.91.96.134:5070;transport=udp,
sip:67.88.208.198:5070;transport=udp,
sip:66.104.81.70:5070;transport=udp,
sip:67.110.56.198:5070;transport=udp,
sip:67.90.80.134:5070;transport=udp,
sip:67.106.133.198:5070;transport=udp,
sip:67.111.81.6:5070;transport=udp,
sip:67.90.152.70:5070;transport=udp,
sip:71.5.91.70:5070;transport=udp,
sip:207.155.164.198:5070;transport=udp,
sip:67.88.84.6:5070;transport=udp,
sip:67.90.177.70:5070;transport=udp"
SIPProxyMode=1
SIPClientTransactionTimeoutOverride=6000
UserDomain=talk4free.com
SIPUnavailableDurationOnNoReply=1800
SIPSessionTimerRefresher=0x00000001
SIPSessionTimerEnabled=0x00000003
SIPSessionTimerDefault=600

[az2008]

The proxy information is returned (again, encrypted) from the provisioning server.

When does it contact the provisioning server? When I watch it using Wireshark, the very first thing it does is contact the proxy using an IP address.

That's why it seems like it must be storing it locally. It doesn't contact other servers until after contacting the proxy.

Mark

[MagicHack]

The proxy information is returned (again, encrypted) from the provisioning server.

When does it contact the provisioning server? When I watch it using Wireshark, the very first thing it does is contact the proxy using an IP address.

That's why it seems like it must be storing it locally. It doesn't contact other servers until after contacting the proxy.

Mark

It is done over an https connection - you'd need to filter based on 'ssl' within wireshark. If you run a tool like fiddler, you'll see it connect to something like:

Code: Select all

https://prov1.magicjack.com/softphone/provision/?dbkey=SOME_ENCODED_TEXT&version=20080822000001&osname=Win

As you can see in fiddler though, the data is now encrypted. (You can also find this URL in the magicjack.exe memory space - just pmdump it.)

When the softphone starts up, it requests that URL, and decrypts in. In there is that [SIP 2.0] info posted above...

[az2008]

When the softphone starts up, it requests that URL, and decrypts in. In there is that [SIP 2.0] info posted above...

When was the last time you traced this? I just ran Wireshark again. It was sitting on an ARP line before starting the softphone. When I started the softphone, the very next line to appear was the SIP protocol connection to the proxy (using an IP address). There was *nothing* between the ARP line (before I started the softphone) and the SIP register.

There is an SSL connection to the provisioning server. But, it is later. And it connects by IP address. There is no DNS call to resolve prov1.{blah} into the IP address it uses.

I do see other DNS calls (I'm not omitting them).

Mark

[MagicHack]

When the softphone starts up, it requests that URL, and decrypts in. In there is that [SIP 2.0] info posted above...

When was the last time you traced this?

I traced it about 30 seconds before posting.

The wireshark capture is below:


It connects to 67.90.152.80 (which is prov1.talk4free.com). That ssl connection contains your credentials (which are encrypted).

Those credentials contain the proxy list that I posted earlier.

[az2008]

It connects to 67.90.152.80 (which is prov1.talk4free.com). That ssl connection contains your credentials (which are encrypted).

Those credentials contain the proxy list that I posted earlier.

I agree. I see the same thing. But, it happens *after* the softphone connects to the proxy server.

Which is why I thought MJ is storing the proxy server's IP address in the profile.db. It's storing it somewhere (because it's connecting to the proxy before connecting to the provisioning server).

Strange.

Mark

[mjsbz]

This is why IP tables would be the only solution. If you take the address of the proxy (assuming that you know where its going) and forwarding it via IP tables, you would be able to change the proxy that you are using.

[az2008]

This is why IP tables would be the only solution. If you take the address of the proxy (assuming that you know where its going) and forwarding it via IP tables, you would be able to change the proxy that you are using.

I will put $5 in your PayPal account if you figure out how to do that.

Anyone else?

Mark

[IanNoga]

I'll pay $19.95.

[Rickiev]

Hmm, I'm in area code 718 and dont have a problem. Even when I called my home number before I disconnected it, I did not have an echo problem.

I even called my friend next door to see if there's and echo and nothing.

This is a well documented phenomenon - dialing same area code causes echo. Seems to especially affect New York.

It is an issue with the phone company servers, unfortunately.

You can get the echo to go away with the *67 trick, but no one has found any other resolution.

Thanks to other posts I found on this forum I tried the *67 "trick" to see if I could get rid of the horrible echo. Sure enough, it did!!! I'm a happy camper (no thanks to MJ tech support). If I dial 718-xxx-xxxx I still get an echo (even if I just call a home depot that has an auto-attendant pick up the phone - if I talk to the answering machine I hear an echo). But if I dial *677*18xxx-xxxx there is NO echo

See this thread: http://www.phoneservicesupport.com/echo-t974.html

[IanNoga]

That is because your proxy is not congested like the miami proxy. That is why I have used the 585 (New York) proxy in order to make clear calls without an echo or choppiness.

[Trebuin]

Anyone still looking for a solution? I very close to finished, but it requires a linksys router.

[JohnnyFreightTRAIN]

Unplug your magicjack and plug it back into another USB port.

LOL, Just kidding!

I suggest you contact bell south and try to get the issue escalated to their engineers. I did that with my cell phone company when I kept getting a busy tone calling all magicjack phone numbers. Of course, it's probably best to just tell them that you are calling a landline with YMAX COMMUNICATIONS rather then a VOIP line with magicjack. Otherwise they will most likely point to magicjack right away because they are VOIP. So that's what I did.

Also try magicjack tech support, no doubt you will get some clueless people but just be patient and ask to be escalated to another representative and/or re-open the chat session with someone new. I contacted both companies with my busy signal problem and it was fixed the next day, both companies escalated the issue to their engineers and both took responsibility for the issue. (well magicjack did when I got a proper tech support worker, before that it was a bunch of canned responses from a rude guy who claimed to be the head of tech support. Once that was over with the new tech support worker understood my problem right away)

Some people have had results by using a DSL filter on their magicjack, if you haven't tried that and have on lying around test it out. It may work for ya. You may also want to try the *67 fix, which isn't really *67 anymore since the latest upgrades. If you don't know how to do it, just dial the number like this: 5*55-555-5555 ... Be aware that the softphone will probably try to dial before you have entered all the numbers, that's normal. Just let the call fail and click on the number again in your call logs, then you can type the rest of the phone number in the softphone space.
Apparently, this is supposed to re-route your phone call.

My last suggestions would be, if you have the older magicjack hardware, which I'm guessing you probably do because you've had it for so long... Download and try out the tiger jet echo cancellation utility. And as a last resort, contact Dan at his AOL email address for support. He usually gets things fixed.

P.S. - Sorry if some of these have been posted already, the thread got long and overwhelming so I didn't read all of the replies..