The Epic Android Thread - Page 103 - maemo.org

danramos | # 1021 | 2010-11-07, 22:45 | Report

Originally Posted by Capt'n Corrupt View Post

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.

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'.

Capt'n Corrupt | # 1022 | 2010-11-07, 23:07 | Report

Originally Posted by danramos View Post

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'.

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.

The Following 2 Users Say Thank You to Capt'n Corrupt For This Useful Post:
danramos, dgec

danramos | # 1023 | 2010-11-07, 23:24 | Report

Originally Posted by Capt'n Corrupt View Post

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.

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/

The Following User Says Thank You to danramos For This Useful Post:
Capt'n Corrupt

Capt'n Corrupt | # 1024 | 2010-11-08, 13:28 | Report

Originally Posted by danramos View Post

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/

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...

The Following User Says Thank You to Capt'n Corrupt For This Useful Post:
danramos

Capt'n Corrupt | # 1025 | 2010-11-08, 14:59 | Report

This is probably the most enticing [rumored] deal for the Tab yet and it's for Australians. The deal? Galaxy Tab for $0 with a $59.99/mo data package with 10-20GB of bandwidth.

http://ausdroid.net/2010/11/03/galax...-20gb-of-data/

This is not to crazy a proposition surprising as this carrier offers completely subsidized netbooks for ~$39.99/mo on a two year.

The Following User Says Thank You to Capt'n Corrupt For This Useful Post:
danramos

danramos | # 1026 | 2010-11-08, 18:39 | Report

Originally Posted by Capt'n Corrupt View Post

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...

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.

The Following User Says Thank You to danramos For This Useful Post:
Capt'n Corrupt

Capt'n Corrupt | # 1027 | 2010-11-08, 19:18 | Report

Originally Posted by danramos View Post

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.

As it turns out SIP uses UDP or TCP depending on the setup and each with its benefits (of course). I think that UDP is more widely used, though and packet loss/out-of-order reception is an accounted for problem.The trick with 'handing off' (I would imagine), is setting a realistic timeout before declaring a connection dead, and a smart enough server that updates its records on re-registration and automatically forwards traffic to the correct IP in that instance.

In the end, it's probably just easier to choose the appropriate network

(eg. cellular WAN) based on your usage expectations.

SIP is a zany world full of infinite configurations. The basic menus/call-answer that we're used to are the tip of the iceberg.

On another topic, if/when you decide to venture forth into the world of SIP, avoid Asterisk like the plague (I have been given such advice from those who know much more than me on this subject). Try Freeswitch instead, which is modular and just as importantly: stable.

The Following User Says Thank You to Capt'n Corrupt For This Useful Post:
danramos

danramos | # 1028 | 2010-11-08, 19:18 | Report

Originally Posted by danramos View Post

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.

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.

The Following User Says Thank You to danramos For This Useful Post:
Capt'n Corrupt

Capt'n Corrupt | # 1029 | 2010-11-08, 19:19 | Report

Originally Posted by danramos View Post

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.

Hahahahah! +1

The Following User Says Thank You to Capt'n Corrupt For This Useful Post:
danramos

Capt'n Corrupt | # 1030 | 2010-11-08, 19:27 | Report

Remember the Epic citidel demo on iOS? Well it seems that it's been put into its first game, and it is truly 'epic'. The game is called Infinity Blade, and can be seen in action here:
http://www.youtube.com/watch?v=q4MTaQ8KkUM

When I see things like this, I instantly understand the iOS appeal. I suppose it's good to know that Epic has committed to developing for Android, and so its likely that we'll see titles like this on our Galaxy Tabs.