Magic jack with the T-mobile G1.

crusader · Post by **crusader** » Mon Mar 16, 2009 10:46 pm

Is there any way to use magic jack with the G1? Now i do not have a G1 yet, but i am getting one next week. So i am trying to think of a way to use it. Maybe in combination with Fring. Do you think that would help? Or just use this Call forwarding Assistant For Magic Jack (Version 2.1 Added)?

crusader · Post by **crusader** » Tue Mar 17, 2009 9:09 pm

Okay, so am i to believe this can not work. Or, Am i just being ignored because this it to hard for you tech's to handle. lol.
Any info would be nice.
Thx.

mberlant · Post by **mberlant** » Tue Mar 17, 2009 10:00 pm

It is probably that nobody has tried it with the G1 yet. As with any other client device, you need to be sure that you have a SIP client installed and working on that device, and then put your MJ credentials in.

I recommend you look in the appropriate G1-related forums to find out how well the G1 works with VoIP services and what those users' favorite SIP client is.

arcadia2uk · Post by **arcadia2uk** » Wed Mar 18, 2009 9:50 am

A G1 is probaly not fast enough to receive a decent signal from MJ - I don't have a clear signal in a G3 Network

kash · Post by **kash** » Thu Mar 26, 2009 12:01 pm

arcadia2uk wrote:A G1 is probaly not fast enough to receive a decent signal from MJ - I don't have a clear signal in a G3 Network

1. 3G
2. It's fast enough

Wifi can handle VoIP. EDGE should be able to clear it, minimal stuttering depending on codec.

mberlant · Post by **mberlant** » Thu Mar 26, 2009 8:05 pm

kash wrote:EDGE should be able to clear it, minimal stuttering depending on codec.

Which CODEC would you recommend, the G.711μ CODEC that MJ requires or the G.711μ CODEC that MJ requires? If you can't squeeze 80kbps in each direction out of your EDGE connection you will not have reasonable call quality. If you can't squeeze about 68kbps out of your EDGE connection you won't have any conversations at all.

dishe · Post by **dishe** » Fri Mar 27, 2009 1:09 am

mberlant wrote:
kash wrote:EDGE should be able to clear it, minimal stuttering depending on codec.
Which CODEC would you recommend, the G.711μ CODEC that MJ requires or the G.711μ CODEC that MJ requires? If you can't squeeze 80kbps in each direction out of your EDGE connection you will not have reasonable call quality. If you can't squeeze about 68kbps out of your EDGE connection you won't have any conversations at all.

I've carried G.711 voip calls over EDGE data connections with ease. It wasn't the best quality, but bandwidth speed was NOT the problem. Remember, EDGE is really 2.5G (it was an upgrade to the older 2G dial-up speed GPRS network) and can reach peak speeds of 230+kbps. Back in my GSM days, I had no problem averaging 130-160kpbs in an EDGE signal area with a couple of bars.

The problem, however, is latency. Cellular connections tend to have much higher latency than other data networks, which means regardless of the bandwidth speed, you'll have echo and annoying audio delays and stutters.
Thankfully 3G networks reduced latency as well as raised overall bandwidth speed. Just FYI.

trek101 · Post by **trek101** » Thu Apr 02, 2009 1:43 am

In regards to utilising a mobile aircard to push VoIP and to make it work is possible. Granted I have only utilised the EV-DO networks (i.e. Verizon, Sprint PCS, etc.). The latency is normally in the 100 ms; generally it is abit high to really support VoIP, but it is possible. Using the MJ dongle on my notebook via the aircard is mediocre at best since you don’t have control on which proxy server to utilise with the lowest latency. Surfing the NET while one phone: forget about it =)

As stated by another user; G711u utilises about requires about 80 kbps of bandwidth. G729 is in the neighbourhood of 30 kbps in my opinion it works fairly well; since the sampling rate is less than the G711u counter part the audio range is narrower, but acceptable for most average hearing folks.

With all that in mind; I am utilising a D-Link DIR-450 aircard router with a Verizon EV-DO rev. A (PC5750 by Verizon) and a Linksys RTP300-NA has worked better than expected. Since I travel a lot to different tradeshows throughout the year this setup work quite well and all of my equipment including my credit/debit card processing terminal utilises a 12 volt DC backplane, I am able to have everything running on a 100 amp hour sealed lead acid battery for the entire day.

Pending the site I am at, I just ping the list of proxy servers to find the one with the lowest latency; plug it in and away I go.

As for GPRS, Edge, UMTS, or HSDPA. I really don't have any experience in that region; if my memory serves me correctly it is based on the GSM format which I personnaly avoid, because of the RFI issue and it wrecks havoc with my EMT gear. If the available bandwidth is correctly quoted. I would try G729 codec and see how well it works. As always the lower the sampling rate which means lower the bandwidth usage, but you will sacrifice voice quality in exchange...

mberlant · Post by **mberlant** » Thu Apr 02, 2009 8:33 am

trek101 wrote:The latency is normally in the 100 ms; generally it is abit high to really support VoIP, but it is possible. Using the MJ dongle on my notebook via the aircard is mediocre at best since you don’t have control on which proxy server to utilise with the lowest latency.

Latency alone is not your inhibitor. If it were, then I would not be able to survive. My US connections enjoy about 250ms latency, about 275ms to Europe and about 175ms to Australia. All of these connections are of very good to excellent quality.

Having said that, it is possible that the cellular network is compressing data packets before transporting them. If this is the case, as it certainly is with satellite ISP uplinks, packets that end up smaller are transported earlier than those that end up larger. By virtue of starting out smaller, like your PING to test for the nearest server, or compressing to a smaller size, like transmitting an email message containing clear text, these smaller packets get through to the other side faster than RTP packets that are both "full" and uncompressible.

An indicator of this phenomenon, though not very scientific since we can't put a sniffer on the data stream, is to place a test call or ten. If you hear the ringback in your ear fairly quickly but then have marginal voice quality once the call is answered, this may be your problem. The SIP packets, being very small, travel smoothly and quickly, but the RTP packets get held up by the attempt to compress them.

It's just my theory, based upon real world attempts to use SIP over two-way satellite. Aside from having to enlarge timer T1 to compensate for a nearly full second of transit delay, the killer is the upstream compression that cannot be avoided.