Thanks for all the input. Sounds very interesting. I didn't realize that UMA isn't VoIP. I don't want to use t-mobiles system. I was thinking of how I could do it without using their system, but the same idea. Sounds like I have got a lot fo reading ahead of me and that this problem is bigger than I thought it would be. Just to make sure I got every thing right GPRS is to slow. Inorder to get something like this to work you need the following: Client software capable of handling 2 streams sip and gsm. It also has to know when to hand over from one to the other. You also need a server that can handle the 2 streams and know when to throw away the extra data. Does that sound right? Just want to make sure I understand what you guys wrote. That IMS thing sounds interesting I will have to do some research on that. Thanks for the info.
<br><br>
<div><span class="gmail_quote">On 6/8/07, <b class="gmail_sendername">Luit van Drongelen</b> <<a href="mailto:openmoko@luitvd.net">openmoko@luitvd.net</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">To get back to what Mathew asked: I don't think a T-Mobile<br>HotSpot@home is switching calls back and forth as you get in reach of
<br>a hotspot, and walk away from it. Secondly: this only works with<br>T-Mobile! (for now) T-Mobile has probably set up a HotSpot@home call<br>server near their GSM traffic backbone, on which your phone logs in,<br>and through which your GSM traffic goes (with that UMA protocol) while
<br>you're logged in (in reach of a public (T-mobile) hotspot). Calls that<br>already take place can't be re-routed I guess...<br><br>Anyway, what I'm trying to say is that firstly: you need T-Mobile as<br>your operator. Secondly: you need that T-Mobile HotSpot @home plan.
<br>Thirdly: you need a phone that's capable of routing your GSM traffic<br>through UMA, to the T-Mobile UMA server/backbone/whatever they call<br>it. As for the Neo1973 and OpenMoko: The phone can most likely do it,<br>
because the software just needs to know how to do it. BUT, I don't<br>think T-Mobile will tell you how to log in. T-Mobile makes the phone<br>software themselves for a reason. If they show you how to make a phone<br>log in, you can make a program that logs your computer in too. So a
<br>FOSS solution for this probably won't come easily.<br><br>--<br>Luit<br><br>PS: sorry for the double post Johnson, it bounced because I mailed<br>from the wrong account<br><br>On 6/8/07, Al Johnson <<a href="mailto:openmoko@mazikeen.demon.co.uk">
openmoko@mazikeen.demon.co.uk</a>> wrote:<br>> Check the archives for a full discussion of this. In short GPRS is unsuitable<br>> for VoIP because of the high latencies, often in seconds. The GSM data mode<br>> is more suitable even though it's only 9600. It should be possible to have
<br>> Asterisk route calls to the right VoIP endpoint, or to a GSM voice call if it<br>> can place calls to the PSTN. The trick comes in knowing when to hand over,<br>> and having a unified client that'll get Asterisk to do it.
<br>><br>> On Friday 08 June 2007 06:21, kenneth marken wrote:<br>> > mathew davis wrote:<br>> > > Dear community,<br>> > ><br>> > > I am not sure if this is a widely known thing or not, but I just found
<br>> > > out about it and had some questions about this working on the neo.<br>> > > T-mobile has hotspots all around my area, but have been experimenting<br>> > > with a new service called T-mobile HotSpot @Home. It uses a UMA
<br>> > > (unlicensed mobile access) technology to allow phones to switch from<br>> > > cellular connection to Wi-Fi connection. And also makes it possible for<br>> > > VoIP calls. So this is something that is very interesting to me only I
<br>> > > would like it to be a little different, I don't want to use T-Mobile's<br>> > > service I would like to use my Wi-Fi connection to my VoIP of choice. I<br>> > > know this has been talked about before with some options including an
<br>> > > Astrex box forwarding the call to your cellphone until your in range<br>> > > then switching to Wi-Fi but that was not a very seamless transistion<br>> > > from my understanding. So I guess my question is could we impliment a
<br>> > > UMA type of technology for the neo that is customizable to use our VoIP<br>> > > provider? Or since that particular part is locked we wouldn't have<br>> > > access to that part? Just curious. When I get the phone I will be
<br>> > > playing with trying to find a solution to this problem. I have very<br>> > > limited knowlege about this kind of thing. I am not an experianced<br>> > > programmer yet. I only have about 3 yers of indestry experiance, but
<br>> > > none of that is mobile development and almost none of it is linux<br>> > > related, so I have a bit of a learnign curve so that is why I am asking<br>> > > the question here.<br>> >
<br>> > while not fully up to speed on how it all works, here is my quick take<br>> > on it:<br>> ><br>> > as long as its a voip connection, and said voip service allows two ip's<br>> > to share a account and call, there should be little to no problem having
<br>> > both a wifi and gprs connection open at the same time as one moves about<br>> > (in my experience a gprs connection can be held open but not used).<br>> > hell, one may even use bluetooth if it can handle the data transfer.
<br>> ><br>> > the problem here is that ip thing. UMA has a normal mobile phone<br>> > connections as one option so therefor dont have to think about multiple<br>> > ip's. it just need to have a internet connected cell so to speak, and
<br>> > only hand the call over when the ip based connection is fully in place.<br>> ><br>> > however im guessing there are some issues with going between two wifi<br>> > zones/networks or something similar...
<br>> ><br>> ><br>> > so mostly you need a voip service that allows you to log in from another<br>> > ip without booting the old connection off or hanging up any calls. after<br>> > that its mostly a case of the client software figuring out what of the
<br>> > two connections to send on. or maybe just send on both, expecting the<br>> > service to throw away the data thats a duplicate. something that i think<br>> > is a basic feature in mobile phone systems.
<br>> ><br>> > one funny thing is that if your using voip, and have a flat rate data<br>> > plan for your mobile phone, there is no need to go wifi anyways as the<br>> > mobile data connection will probably be more reliable given that its
<br>> > already built to do what one is trying to make the wifi system do<br>> > (handover, multiple connections and overlapping zones).<br>> ><br>> > _______________________________________________
<br>> > OpenMoko community mailing list<br>> > <a href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a><br>> > <a href="http://lists.openmoko.org/mailman/listinfo/community">http://lists.openmoko.org/mailman/listinfo/community
</a><br>><br>> _______________________________________________<br>> OpenMoko community mailing list<br>> <a href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a><br>> <a href="http://lists.openmoko.org/mailman/listinfo/community">
http://lists.openmoko.org/mailman/listinfo/community</a><br>><br><br>_______________________________________________<br>OpenMoko community mailing list<br><a href="mailto:community@lists.openmoko.org">community@lists.openmoko.org
</a><br><a href="http://lists.openmoko.org/mailman/listinfo/community">http://lists.openmoko.org/mailman/listinfo/community</a><br></blockquote></div><br>