Short version: Does the T-Mobile network allow incoming UDP packets?
Longer version:
I'm writing a small test app that connects two Androids over a mobile network. It works over LAN but not over 3g.
Most carriers block incoming TCP connections over their networks, Does the same restriction apply to incoming UDP?
I've recently been testing UDP port forwarding on 3G from T-Mobile Slovakia (Deutsche Telekom) and found that it's not possible. They are using Symmetric NAT which will prevent you from communicating endpoints between two peers because one peer's incoming port will depend on another peer's IP address. I wrote a bit more about it here.
I've not yet had problems with O2 Slovakia (Telefónica) in this regard.
EDIT: This may be irrelevant now given that the question is 5 months old, but since you mentioned building a test app, the best tutorial on NAT traversal I've found is IMO this one.
Related
I'm trying to write an Android app to accept TCP connections from the Internet. Sounds simple but despite weeks of head-banging, I've found no solution and now believe it impossible. I would love to have someone tell me I'm wrong.
I was encouraged by the "ServerSocket()" API function. I was able to create a listening socket (e.g. on port 2000) and connect to it from another app within my device. Unfortunately I find it is bound to (unrouteable) local address 10.0.0.150 which, of course, cannot be seen from the Internet.
I was also able to successfully connect by pointing my device to my local WIFI router and using the router's "Port Forwarding" feature to relay incoming connections to MyPublicIp:2000 to 10.0.0.150:2000. But this is not usable in the field (over an LTE connection) where I have no router.
I've searched StackOverflow and other sites but found no good answer (but plenty of inapplicable or obtuse ones).
From my reading, I hear that most (all?) carriers do not allow incoming connections to be routed to user devices, which may explain my dilemma.
PLEASE: Someone tell me I'm wrong.
I think it is possible.
Looking information about my mobile operator (mobile provider): it can provide a static IP address and my mobile device is available for incoming sessions, but only need to pay for this service.
I cannot figure out how to send a UDP packet over a 4G LTE network from an Android app (no WiFi). Does anyone have any ideas or know where I can find some documentation? I need to write two android apps, one client and one server, so that I can send UDP packets with timestamps from one device to the other. This is to test 4G LTE network latency from device to device.
Please help!
Thanks!
You can use the DatagramSocket class:
http://developer.android.com/reference/java/net/DatagramSocket.html
This should work regardless of WiFi or mobile connection type, although you may find some mobile operators have some restrictions on UDP connections.
There are many existing Android Iperf apps that can be used for exactly what you are trying to do. I use Magic Iperf to do this type of testing myself.
I'm just confused about how SIP works but mine doesn't.
I made a simple android server which open up a server socket and listen to incoming connection on 3G/4G network. Then I made a client that connect to the server, the connection was blocked by my carrier's firewall(AT&T).
After this, I downloaded an open source VOIP app based on SIP, and register these 2 phones on SIP proxy, let them call each other, this works perfectly.
I'm just so confused about how SIP works on cellular network, SIP is a p2p protocol, SIP proxy is just for redirecting. How does these 2 phones connect to each other in VOIP session? Why is this connection not blocked by carrier? Can someone explain to me? Thank you in advance!
update: I just tried sending a UDP packet between AT&T and SPRINT network, it does not work ;(
In basic SIP the endpoints media traffic generally communicate directly between each other in a P2P fashion like you said. They do this be giving each others address/port in the SIP SDP negotiation.
In a "perfect" network world this works fine as all endpoints can talk directly between each other.
As we know, this is not the case.
In most cases, the main barrier in the IPv4 world is NAT.
The first solution people came up with is STUN. STUN will give you your "public" IP address that you are using from behind a NAT and the SIP stack will use that IP address in the SIP/SDP packets. This works as long as hole punching works.
The next solution people came up with is TURN. TURN is a UDP proxy and allows a client (e.g. a SIP client) to allocate and use a IP address/port on a private network from a public network (i.e. the internet). It should work in all cases but can put a lot of network overhead on the TURN server. It will not be as efficient as P2P connections tho. The upside of using TURN is that not both sides need to support it for it to work. So it's good when you are talking between a softphone on the internet to a hardware SIP device on a internal network.
The next solution people came up with is ICE. ICE needs to be supported on both SIP endpoints. It works by extending the SDP protocol to allow it to add all possible connections in the SDP negotiation (all local network adapters, public addresses provided by STUN and TURN allocated addresses in priority order). Then one side goes through the listed connections and tries to make a connection. This allows both connections to be "try" to connect P2P and fallback to a TURN connection if nothing else works. It should also work in any networked environment to any networked environment and find the most efficient network path between the SIP endpoints. The downside of ICE is that both SIP endpoints need to support ICE for it to work. (As a aside, ICE/TURN/STUN is now a requirement for the WEBRTC protocol for web browsers to talk between each other for the same reason)
Other possible solutions would be for you to have some sort of "smart" sip proxy in the middle that maybe fakes ICE on one side if the other side doesn't support it. Another is to have some sort of media gateway or B2BUA if transcoding is required, this would have the same problems as TURN tho.
I would suggest that you setup your SIP client with STUN, TURN and ICE if possible and that will increase the likelihood of the SIP call actually working.
As to why your case doesn't work now, it would require network and/or SIP logs to understand what the exact impediment is.
My question is whether port knocking can help me in the situation stated in this question (socket connection issue between 2 carriers' network) to allow connections between an android server and android client?
Depending on the carriers, you may be able to. Verizon (in the US) sometimes uses NAT when they run out of IPs. If the Verizon device is a mifi you could wind up with double-NATed routes, but even simple NAT requires the use of UPNP (not generally supported by the routers they use), or an external server to penetrate the network, such as SIP or STUN.
I want to write a program to access my Android phone's camera on my laptop wirelessly, so, my phone will act like a wireless webcam.
I want to implement the UDP ( or TCP ) protocol in Java to communicate between my laptop and phone.
I was thinking of making an ad-hoc wireless network in my laptop and connecting my phone to it first, and then write the code to create a server socket on my laptop and client socket on my phone.
I know this code will work for a "direct communication" between server and client. but will this method of ad-hoc network communication count as a "direct communication" ?
If not, what do I do to achieve this ?
Thank you, firstly for reading my whole problem, and,
thanks a lot if you can answer this for me
:)
First of all: Don't concentrate on ad-hoc networks. In most cases WiFi with infrastructure mode access points will be available. If on the road, all recent versions of Android are able to act as a wireless access point.
So let's assume both devices are connected to the same network and are able to reach each other (using the IP protocol) - in other word they are able to ping each other. The next issue you have to solve is: How do both applications find each other? Bonjour/Zeroconf might be a solution (see Are there any other Java libraries for bonjour/zeroconf apart from JMDNS?).
The next question is: What protocol you want to use? You mentioned TCP and UDP. In most cases UDP will be used for transmitting video data, because you have a lower latency and the video codecs are tolerant on missing packets.
With this information you can create a ServerSocket and (from the client side) know where to connect to it.