I am trying to make a sip call by using android.net.sip but have registration problem.
All responses from the server (I tried multiple servers) correctly reached UDP port number that is described in the Via and Contact headers of the Register.
However, all of responses got ICMP port unreachable.
I am using AVD running on XP machine and I verified both isAPIsupproted and isVoipSupported.
I would appreciate if you can provide a solution.
Does the response packet reach the port which REGISTER packet sent from?
It seems the emulator only listens on the loopback interface (check with netstat, etc.), so if you want to get incoming connections, you need to port forward incoming connections on the host machine's LAN interface (eth0, etc.) to the corresponding ports on loopback. I haven't tried this though, so it's all theoretical.
Related
I created a VPN using android's VPNService class. Now, I want this VPN to also handle packets from the device's hotspot interface. So in the VPNService Builder, I called the addRoute("0.0.0.0",0). This made sure I got all outgoing packets including the Hotspot.
The problem I am currently facing is that when I get packets redirected from the hotspot, the packets seem to still have IPs from the hotspot network. 192.168.43.... both in the source field and destination fields of the IP packets and the payload doesn't seem to contain a TCP packet either.
My questions are:
Why does the hotspot packet I receive from the VPN interface not have the same source IP as that of the VPN interface created by VPNService class?
Is there another layer the packets from the hotspot are packaged for since I can't seem to get a remote Address for the real request in the IP headers?
Is my VPNInterface setup wrongly?
My interface was setup correctly.
Apparently, what I was getting then were DHCP packets. DHCPOFFER Packets from Android's Local DHCP Servers.
Even though android's VPN interface is setup to get all outgoing packets on a device, it doesn't seem to get broadcast packets but for some reason, it gets replies to broadcast packets.
I wonder why it was designed that way.
Understanding this helped me solve my problem.
I am trying to build an embedded device that would be connected to a router.
But I want to be able to know if the device is connected to the router or not using a PC or Mobile.
For example:
How can the PC detect if the google chromecast is connected on the same network or not ?
Do I need to communicate with each IP in the network on a specific port to ask ?
Or do I need to let the embedded device broadcast some information every N seconds ?
Thanks,
In any case you should consider doing a Gratuitous ARP on your embedded device. A gratuitous ARP will announce to all of the devices on your LAN that a new device has joined so they can update their ARP cache.
As far as a PC/Mobile device discovering your embedded device goes, you have a few options:
Option 1
If we can assume that this is a typical flat home network where all of the devices are on a single subnet and there is one gateway router * then you can give your embedded device a unique OUI. If you intend to sell this device you will need to apply for an OUI with the IEEE anyway unless whoever made your chipset supplies it with a MAC address already. Your PC/Mobile app can periodically check its ARP cache for an OUI that matches the unique OUI that you expect.
This will not work if the network is not flat and there are multiple routed subnets or VLANS. Here is a possible scenario: Lets suppose your embedded device connects to a client bridge range extender. If your PC/Mobile app is on the main access point it will never see the MAC address of the embedded device - instead it will see the MAC address of the client bridge. Multiple IPs will be mapped to the client bridge because the client bridge and the client bridge will be switching packets.
*I put the term router in italics because most home routers are merely doing NAT between the WAN/LAN and the LAN side of the router operates like a layer 2 switch.
Option 2
You can do a broadcast ping request, eg. ping xxx.xxx.xxx.255. You'll get a response back from all devices that will accept a broadcast ping request. Just make sure your device does. Then once you have a list of IP addresses you can attempt to open a TCP socket over the arbitrary port of your choosing with all of those IP addresses and then send some unique handshake packet. Your embedded device should be listening over this port and should have some unique reply to this unique packet. Most of the devices on the lan should generally not allow this socket to open, but if they do they should not understand the unique handshake message you send.
Option 3
Send a broadcast UDP datagram with some unique handshake payload. Then your embedded device should reply to the sender of this broadcast UDP packet with some unique response. After this response has been received by your PC/Mobile app you can then open a TCP socket with the IP address the response came from.
I have 2 Android apps, one is the server, and the other is the client. Both communicate each other by udp sockets, in both ways. What i need to do is in the client app, a method to check what ip from my local network is listening to my specific port (to set this ip as server ip).
Do i need to implement some kind of method in the server to return an upd package when certaing message is received (the "test" message), and shoot every single ip from my local network until one responde? or there is a better approach?
Thank you for your time
You have two options:
Have the server publish its listening IP:Port somewhere that the client can read it from.
Have the client send a single UDP packet to the broadcast IP address of the desired network subnet. Presumably the server is on that same subnet, so it can receive that packet and respond back to the client directly. Then both parties will have each other's IP:port values.
Either way, there is no need to have the client send a packet to every IP on the network manually.
I've installed Linphone on my Galaxy S2 device and I ran tcpdump on it to capture SIP traffic that Linphone is sending to my Asterisk server. I noticed that sometimes my device sends a special packet from UDP port 3526 to my Asterisk server port (5060) that contains:
HEX: 0d0a0d0a
ASCII: 13101310
Wireshark resolves this port (UDP 3526) to starquiz-port (this name is not useful because most clients use ephemeral ports). I searched the net about this port and starquiz. The only useful information that I found is this link at IANA. Does anyone know what is this packet, and why my phone is sending it to Asterisk?
PS: In section 3.5.1 of RFC 5626 a keep-alive using CRLF is mentioned but it is only for connection oriented protocols:
CRLF Keep-Alive Technique
This approach can only be used with connection-oriented transports
such as TCP or SCTP. The client periodically sends a double-CRLF
(the "ping") then waits to receive a single CRLF (the "pong"). If
the client does not receive a "pong" within an appropriate amount of
time, it considers the flow failed.
You softphone can use any port.
That is normal.
Softphone or asterisk(if set qualify=yes) can send empty udp packet for keeping NATed connection active. That is also normal.
I highly recommend you read more about SIP before dooing any softphone or other sip-related programming.
All of the documentation, examples and questions I've seen so far on TCP connections with Android have been between an Android device and a computer. As unreliable as wireless can be, is it possible to make a client-server TCP connection between Android devices over WiFi, and if so, how?
Edit: I guess I should elaborate more on my situation.
My Droid does not respond to ping or accept incoming TCP requests from anything unless I first make the Droid a client and my laptop the server. After this initial connection is established I can then ping from my laptop, or make the Droid a server and my laptop the client. What I can't do is make one Droid the server and another a client, I always get a "No route to host" error.
It feels like there is something blocking incoming connections unless the device initiates a connection to something else, and even then the only request the device will accept is with this device. How can I make my Droid a server that accepts all incoming TCP requests from any device on my local intranet?
You should be able to. Just do like you would do with computer/device connections, except run the client and server code on the devices.
One of the neat things about the Internet is that the Internet doesn't care whether you are establishing a connection between two PC's, a PC and a phone, or two phones. I would look at the Socket documentation, that should be enough to get you rolling.
It's certainly possible. The only problem is figuring out the IP address. I don't expect a phone have a fixed IP... However, if there is a fixed "login" server somewhere in the Web which IP is known to both phones then they can do a handshake via that server and after that continue peer-to-peer.
re; The only problem is figuring out the IP address. I don't expect a phone have a fixed IP.
Try this;
Use the web browser on the phone to log into this website: It should provide you the IP address.
http://whatismyipaddress.com/