Connecting two Android devices using RTP without any server needed - android

I am developing a VoIP service where two devices can have an audio conversation.
I have been reading about signalling protocols like SIP. I understand the power of SIP but I prefer to have my own signalling protocol since my service will be very basic and will not require the full power of SIP.
As far as I understand, the main purpose of SIP and other protocols is to find the address of the remote party. This information I can get from my server, so no need for SIP here.
Establishing the connection from the caller should be relatively easy.
The problem I am facing however: How can I make the callee Android system listen for RTP packets specific to my app? I need this so I can fire up an intent to deal with answering the call etc.
A ServerSocket has been suggested, but I am not using TCP, and I am trying to make a client-to-client connection, not a server-client one.

SIP is not only used to find the IP address of remote party but also to agree on ports involved in media communication.
For 1-to-1 calls, when caller establishes connection it sends SIP INVITE to callee IP and SIP port. Caller knows that IP because it can query for it from the Registrar server for example.
The SIP INVITE sent from caller to callee has RTP/RTCP ports of caller stored in SDP payload of SIP INVITE message.
When receiving SIP INVITE the callee immediately responds to caller with 180 Ringing, the callee then may display an alert indicating that incoming call is received. Assuming that user accepts the call 200 OK is generated and sent to caller. This 200 OK message has SDP payload with RTP/RTCP ports that will be used by callee to listen for media packets. When 200 OK is received by caller both parties know the ports that will be used for the communication.
If I were you I wouldn't invent any protocols. I would rather try using 3rd party libraries such as pjsip, sofia-sip or some Android SIP stack.
If this is not the case, I would try to adapt the above message flow to your protocol. The problem is that the caller has to know in advance callee's IP and port where signalling message has to be sent. This may be difficult to achieve without any server involved (to query for callee port and IP).

Related

How does a SIP based app scheme work?

This is an abstract question on how the SIP protocol works. Let us say I have a SIP server (Asterisk/Yate). And I have two Android devices that wish to connect to each other to have an audio call. ( I am looking for a purely VoIP call, no need for telephone numbers or carrier information).
How would this work? Do the packets have to pass through the server? or does the connection happen between the end-points. If the packets has to pass through the server, does the SIP server also provides profiles, or do profiles have to be created by a third party?
I need to understand how the scheme works in order to start planning building the system.
I have read lots of technical documentations, but none show an abstraction of the system. If you can provide me with resources, that would be great too.
Thanks
Since your device not know where each other located(ip/port), they call sip server or proxy.
Sip server match dialplan and send request changed(server) or unchanged(proxy) to other side.
In INVITE request each peer send address/port and info about media stream RTP
If that info unchanged(proxy) they can see each other rtp info and send rtp packets directly.
Also there is posible enother INVITE after call bridged,called re-INVITE with info about new stream for rtp(can be sound on other ip/port or video)
There are nothing called profiles in sip standart, sorry.
Anyway seams bad idea start planning voip system if you have limited REAL experience with sip server.
There are alot of articles(including wikipedia), videos on youtube with topic "how sip works", there are no way put all that here in one answer.

Android apps and server connections

I am an android user and of course I use whatsapp, twitter for android, facebook and many other apps that notify me of events.
As a proogramer whats keeps me wondering is how fast notifications or whatsapp messages arrive.
My intuition tells me that is not possible for the whatsapp or twitter server to open a TCP connection with my cellphone by a given port to deliver a new message. If i am in wifi mode the router would block that connection.
And if my whatsapp client is pooling the server every second.... Poor server if it has 1000 clients making request every second.
What is the approach to face this issue?.
Is there some other protocol involved?.
Those apps use services that utilize "long polling" - primarily based on XMPP or some variation of XMPP (like jabber - http://www.jabber.org/). The client does not poll often. A quote for the Wiki page:
The original and "native" transport protocol for XMPP is Transmission
Control Protocol (TCP), using open-ended XML streams over long-lived
TCP connections.
It sends a message to the server that basically is a mechanism for the server to send a message back at any time (as long as the client is available). It's like sending a request to an HTTP server and the server "time-out" does not occur for a very long time (hours), so the client just waits. If the server receives a message destined for the client, it sends a "response" to that request. After the time out does occur, the client sends another request and waits.
GCM does the same thing - but does not require you to setup servers for all portions of the connection. It's easy to search for GCM, AWS, etc. to see examples.
Typically GCM should be used if you dont want to guarantee immediate delivery and it is okay for your app to miss out on certain messages.
This is because GCM tries to optimize by bundling several messages (even from other apps) into a single package. And it has a limited buffer to maintain the messages per device (in case the device is not reachable).
Here is just one way to do the job.

Why do the UDP recipient receive the same packet in twice?

Why do the UDP recipient recevie the same packet in twice? The UDP sender just send one packet to the recipient, but the recipient receive the packet in twice and the two packet are same.The sender and recipient are runned in the differnt device.The sender APP is runned in the android device and the receipient is runned in the iOS device. How to explain this case and how to fix it?
From http://en.wikipedia.org/wiki/User_Datagram_Protocol
UDP uses a simple transmission model with a minimum of protocol mechanism.
It has no handshaking dialogues, and thus exposes any unreliability of the
underlying network protocol to the user's program. As this is normally IP
over unreliable media, there is no guarantee of delivery, ordering or
duplicate protection.
If you want to avoid such scenarios, you'll have to use TCP instead.

SIP service to be used for incoming call

I am trying to automate incoming call to an Android Phone.
I have a sip client on my PC which supports call to Phone Number. For this I need a SIP account which will allow me to make a call to Actual Phone Number. This SIP service should be available in India and US.
I wanted to know
if I make a SIP call to a number will I get Incoming Call Notification in Android Phone?
Can any one guide me which SIP service I can use to have to make a call from PC to phone? This SIP service should allow 3rd party SIP client to connect to it. And also I want to generate just an Incoming call notification in Phone. So Please let me know if there any Free SIP service from which I can achieve this or some cheap service as Audio quality does not matter..
You can use sip2sip.info and it's free. It supports calls to PSTN networks. Check out how you can configure your device.

Android: Find peers on Wifi Network

I'm trying to figure out how to search for other devices logged into a wifi network that are hosting the application on a specific port.
How can I detect the presence of these other devices without knowing their address or even necessarily the port they are hosting on?
Once discovered, I should be able to contact the device and establish a client-server connection with it using SocketChannels.
Note: This application is meant to work with Android devices pre-ICS. So no Wifi-Direct.
You can definitely send a probe packet to broadcast (255.255.255.255) on a well-known port on which all peers listen. This is a good old technique for easy discovery. Others incluse SSDP or UPnP.
Be aware that 255.255.255.255 works only for UDP broadcasts
[Add]
I prefer expanding my answer rather than commenting.
1. Who should initiate a broadcast?
You can choose your favourite broadcast model. They are all interchangeable.
Model 1 is "job offering" and in my opinion is my favourite. You open a listening socket on your server application and then periodically send an advertising or better announcement broadcast message telling everyone that an open service is available at a certain IP/port (the port is not required to be static). Any peer interested in communication simply connects to the specified endpoint to use the service.
Model 2 is "job seeking", in which the server remains silent. When a client wants to connect, it broadcasts a generic seek message. Any server available receives the message and either replies (unicast) or else broadcasts the above mentioned announcement message.
Model 2a is "reverse job seeking" where a client broadcasts a request for service not as a generic message but including its endpoint. The server then connects to the client endpoint but the protocol continues as the client node is requesting a service from the server node. They act as reverse-roles TCP peers.
2. How often?
It depends on several factors. I'm not able to help you choose the final number of milliseconds, but I can show you all of the factors. First, how long should a client wait to tell the user that the scan for available services is "finished"? You may think "instantly", or "1 second", but bear in mind that broadcast packets tend to overload the network according to the number of servers available in a community.
If you choose model 1, start listening for available services ASAP (ie when application starts) and then periodically remove from the list those services whose heartbeat (another technical name for the broadcast packet) is not received within T*2 or T*3 timeframe where T is your timeout. A manual scan is generally supposed to be completed within T*1.5 or T*1.2 depeding on how large is T

Categories

Resources