I have implemented a sip based real time voice transfer under the impression that two of my phones on the same WIFI network can communicate provided that they have each others IP addresses. However, I could not make it work... I am using rtp to transfer voice between these clients.
Also, it's come to my notice that using a PC on the WIFI network as server is better. Now, can I use this PC as a proxy server to establish a sip end to end connection? If yes, how?
Are there existing implementations for initializing a session? Specifically, if someone could give me an example on what address/ports I would need both of my clients to establish the connection to, it would be great.
If you have implemented correctly all the necessary parts that SIP protocol demands, then you have to install a SIP server on your PC and just create two accounts that the phones will connect with them on the server. I have tried with Android the Asterisk server, but I am sure that there will be many others out there...
By default SIP servers are listening on port 5060 using UDP. This port is used only for the initiation of the session (and other control messages) and NOT for the transfer of RTP packets.
Related
Intention is to intercept all the traffic from the android device. I did this previously by creating a local proxy server and manually adding it in the wifi settings of the device. But now to avoid that we need that settings need not be changed and packets get intercepted automatically. For this purpose I employed AndroidVpnService, using this I am able to capture the packets but these are raw IP packets. I am not using the VPN tunnel since it seems it happens to support remote servers while I am having a local proxy server in place. Thus I am using simple JAVA sockets but the raw ip packets cannot be transmitted over these sockets especially due to difference in network layers at which they operate. Any suggestions on how can I make that happen or may be construct the suitable headers for transferring the packets over socket to connect to the internet and get the response back?
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'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.
I'm trying to make the following work, and wonder if it is possible:
I want to send data from a hardware piece to an android device. Although the hardware only has an Ethernet connection available.
If I were to make an Ethernet connection from the hardware piece to a router, and then communicate from the router to the android device with WiFi, is there any way I could tell the android device, just receive data from the WiFi?
Using IP protocol will allow you to communicate over any IP network.
Easiest way to do that is using TCP sockets that uses Server/Client relation to communicate.
I'm guessing you are using a microcontroller (arduino?) if that is the case there are many IP labraries and examples you can look at.
after writing the server code on the hardware then you can easily use sockets to connect to it from android, here is an example on how to connect android client to TCP server.
TCP Client tutorial
Extra links:
TCP on Wikipedia no need to read the implimentation details just understand the concept.
Java All about Sockets Great overview of socket programming and should get you ready to write effective code on the android side.
LAN wikipedea article about LANs
I just want to write an app for andorid which is very similar to facetime on iphone or skype's video. Just want to implement a P2P connection for video transmit and display. Is there somebody who has some related document or code about that. And one thing I want to know is how to establish a p2p connection between two phones? Just need the IP address to establish a tcp connection or I need some other information. And also if two phone are not in the same LAN or have firewall between them, how could I do it?
Thanks!
Typically, UDP is used for applications like P2P audio/video, not TCP. UDP tolerates dropped packets where TCP does not. For something similar to what you described, a protocol like SIP is used to negotiate the connection. With SIP, I register my presence with a SIP registrar which is where I appear. I might have a handle like user#my.cool.sip.example.com. The SIP registrar is sitting on my.cool.sip.example.com and maintains a list of all attached users and their IP address. Connection requests are proxied through the SIP registrar which knows how to contact the user. Since all users of the registrar make an outgoing connection to their SIP registrar, no firewall punching is necessary to initially establish contact. Another SIP client might have a name like user2#their.favorite.sip.example.com. They will connect to their SIP registrar just like I connect to mine. When they want to contact me, they will send a message to their registrar which then forwards it to my SIP registrar. When I send a response back, I send it to my SIP registrar with a destination using their from address. My SIP registrar contacts theirs who ultimately forwards it to the client.