Originally Posted by Capt'n Corrupt

That's great! Tell me something, how well does WiFi to 3G handoff work? I don't own a smartphone, and am curious about this feature.

Originally Posted by danramos

What do you mean? Are you asking how well it handles switching from Wifi to 3G and back to Wifi as far as active open connections go or something? If so, open connetions (TCP) die until they're retried and re-opened... as you'd expect with any switch of interface like a Linux laptop would. Not entirely sure what you specifically mean by 'hand-off'.

Originally Posted by Capt'n Corrupt

Hmmm.... I was under the impression that todays modern devices were NAT-like with routing and would maintain open TCP connections even on a network switch, but I suppose this isn't the case.

I remember reading that Nokia had found a solution to this, and was always curious about how this problem had been solved -- as I understand that its not a simple problem.

Originally Posted by danramos

As someone who has gone from tech support rep in an Internet Service Provider (ISP) all the way up through the ranks to Senior Network Engineer... I can tell you that, short of getting yourself a multi-homed BGP (Border Gateway Protocol) Autonomous System (AS) route for YOUR particular device, you're not going to solve that. NAT is completely irrelevant to keeping an open connection when you're severing from one network to appear on another.

BTW:

http://techcrunch.com/2010/10/30/top-30-android-apps/

Originally Posted by Capt'n Corrupt

Thanks for the clarification. I admit, that my understanding of the various mechanisms of TCP are somewhat paltry -- not to mention the other protocols.

I guess this means that when I'm on a SIP call via WiFi, I better finish up before walking out of the house! Now I wonder if there's support for this type of network via SIP over UDP...

Originally Posted by danramos

Yeah, you would either need to specifically set up the client to be fault-tolerant in some manner (outside of depending on TCP to re-route your session to who-knows-where, from the network side's perspective) or else you would have to use a connection-less protocol like UDP because them each packet frame could identify where the packet is coming from and respond to it in kind. This might open up other issues, though, but it would solve this particular one. Although, in truth, I thought SIP used UDP already? I should go look it up, now that we're going down that road in the conversation.

Originally Posted by danramos

Yeah, you would either need to specifically set up the client to be fault-tolerant in some manner (outside of depending on TCP to re-route your session to who-knows-where, from the network side's perspective) or else you would have to use a connection-less protocol like UDP because them each packet frame could identify where the packet is coming from and respond to it in kind. This might open up other issues, though, but it would solve this particular one. Although, in truth, I thought SIP used UDP already? I should go look it up, now that we're going down that road in the conversation.

Originally Posted by danramos

Well, danramos.. yes and no. It CAN use TCP and it CAN use UDP.

Citing:
http://en.wikipedia.org/wiki/Session...ation_Protocol

"SIP works in concert with several other protocols and is only involved in the signaling portion of a communication session. SIP clients typically use TCP or UDP on port numbers 5060 and/or 5061 to connect to SIP servers and other SIP endpoints."

So SIP could operate independent of the TCP/IP framing--like any well behaved networking application should. So yes--you COULD be using a SIP client that uses UDP and it could conceivably be designed to jump carriers and interfaces if the application layer is written so be so fault tolerant, since it would be the responsibility of the combined effort of the network and application layers to handle such an even.

I hope that answers your question, Dan.