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.
Related
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 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.
I'm a bit confused about the new Wi-Fi Direct feature in Android ICS. Is it possible to create a P2P group with multiple devices, and send multicast packets from a source peer to the other peers?
Unfortunately, I don't have any devices that are Wi-Fi Direct enabled, so I can only browse the examples that I find online. In these examples, I could only find peers establishing 1-on-1 connections. So, is multicasting possible?
Is it possible to create a p2p group with multiple devices ?
Based on the Industry white paper and the technical specs, yes it is possible to create a group with multiple devices, you will have a one-to-many connection, one Group Owner (GO) and many clients.
Send multicast packets from a source peer to the other peers?
Based on the technical specs, the GO shall act as a DHCP server and provide an IP address to the connected clients (which should act as a DHCP client). Each device can easily know its own IP and the GO's IP, so it should be possible to do a broadcast using the address 255.255.255.255.
Regarding a proper multicast, I am not sure, I guess it depends on the capabilities of the DHCP server created.
Maybe I don't understand exactly how works the UUID in a bluetooth connection, but as I have understand, the server has to open a BluetoothSocket with a specific UUID and listen to a connection request on this socket with the same UUID.
My question is, when you don't have access to the client to hard code the UUID, how can you send to the client the UUID he musts use to connect the BluetoothSocket ?
Please tell me if I have not correctly understood the bluetooth connection process !
Best regards
Bluetooth provides a Service Discover Protocol (SDP), which is a standard way of discovering services and UUIDs. When building an app, you can either hard code UUIDs on both server or client, or you use SDP to look up the UUID at runtime.
A bluetooth 'server' can expose one or several services (also called profiles): for example, a server can expose a SPP profile (through the SPP or RFCOMM GUID).
Now, when a client wants to connect and talk a server (which is 'another' BT device around...)
1) the client do an 'Inquiry', that is, list all nearby BT devices, and collect informations about them (Name, MacAddress aso.)
2) the client then select the 'server' device (by name or MacAddress...)
3) if found, the client can then issue a 'Discovery' on this particular device, and collect its list of exposed profiles/services.
4) if the client found the wanted service (same GUID, as wanted), it can connect to it and then 'talk'
tl;dr : the server doesn't 'send' the GUID or whatever. Client and Server both agree to 'talk' with a common 'language', ie same GUID-same profile (if available on both sides ofc)
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.