I am trying to figure out a solution for a signaling server for an Android WebRTC based project. Both clients will be Android and both located close to each other, i.e. - within 100 yards or less. I would like the solution to work without the use of a public signaling server. I would rather just have one of the clients also act as the server.
So, my question is :
1. How can I achieve it so that one is the server? i.e. - Can I set one as a hotspot or use wifi direct?
2. If I can achieve #1, then what is a good solution for a signaling server running on android ? Can I run one of the nodejs servers on android ?
A signaling server is simply a way to exchange messages between two parties. In the WebRTC case these messages are the offer/answer and ICE candidates.
You can use whatever type of server you want to do this, you can even do it manually :).
You can use one of the clients as the server too, but then you will have to communicate the IP to the other somehow. Maybe use Wi-Fi direct and get it programatically.
With WebRTC, signaling server is just the way to help you transfer your message, exchange your information (SDP package(createOffer/answer), exchange candidates etc).
Example : You can use GCM (Free) as a signaling server, or using Nodejs with socket.io, websocket, XMPP etc. Only thing you need is transfer your message between two peers.
You can refer to this tutorial : http://www.html5rocks.com/en/tutorials/webrtc/basics/
Related
I need some help in terms of choosing a design option for my problem.
I currently managed to implement a RaspberryPi acting as a Server and my local machine to act as the client. This client send JSON-Data to the Server which processes these. Everything is working as expected and I am using TCP-Sockets for the communication.
My problem:
The next step of my project will be, that I will use instead of a PC an Android-Device as client. What I want to achieve is, to send data to the server on the go. What I mean by that is, I do not want to restrict the server to be in a special network neither the client. What can be expected, is that server and client are next to each other, like in the range of a bluetooth connection. My question is, is there a relatively simple way to implement this communication? Is TCP a possible solution for this (even working in mobile networks?) or do I need to use Bluetooth, or is the way to go, to create some kind of network the client/server connects to and communicate here?
Sorry for propably stupid questions, but I am new to all this network stuff.
EDIT:
Since there were no respones, maybe I can do a more precise question. Is there a proper way to scan a network for a device name?
The only way I currently can imagine is to do a bruteforce like check on every IP-Address and resolve the names?
I first tried to let the Pi host an ad-hoc network, but it seems that non-rooted android smartphones do not have the possibility to access ad-hoc networks.
Therefore I made the Pi acting as an access point.
The communication now is very simple realized by a tcp server-client system.
I would like to implement a voice chat (even just a primitive support for it), without the hassle of implementing the whole VoIP stack. I would also like to make it available to both iOS and Android.
I have been searching for a way to do this, and it just seems to me that using Socket.IO would be something to start with. Is it possible to use Socket.IO as a signalling server (to discover who is available, and who to start a voice chat with), and then establish a peer-to-peer connection between two devices in order to transfer audio data?
NOTE: Although I would prefer peer-to-peer, because I would like to avoid overloading the server with transferring such an enormous amount of data, is it possible to have socket.io receiving and transmitting audio data between devices (because I heard that iOS and Android cannot establish a P2P connection with one another). If it's not possible, then maybe it's possible to use a socket.io server as an intermediary for sending audio data?
I found the following helpful links (which are probably based on socket.io) but they have not any reference for mobile devices.
http://peerjs.com/
https://simplewebrtc.com/
Any help is greatly appreciated. Any alternatives to socket.io, are also accepted, if there are any.
I'm having the following scenario:
On the PC i will have a program running: java or .net, haven't decided yet.
When a certain event happens on PC i want to notify the android device.
I want a solution as independent and reliable as possible.
Opening a server on the PC/Android i think is out of the question because the user might be behind a router or on GSM internet (as far as i know it can't open ports as server)
The solution i have at this moment is to have a web server on the internet and have it handle the job, but i'd like not to use this because the delay between checks should be around 5 seconds, and i expect to have about 2-3k users simultaneously, and that will probably know down a regular web server.
So, any ideas how this communication can be made?
You may consider the option of Bluetooth client server application since PC and Android device usually have Bluetooth. You will have a Java server running on the PC and an Android client on the device. Check out this post: Send text through Bluetooth from Java Server to Android Client
You can handle the situation where Bluetooth is not available by creating a failover mechanism using REST API & JSON.
If you're already a web developer, I think creating a light HTTP based REST or JSON service would be a great solution. You've already said you don't want to do that which leaves the option of rolling your own client/server set up.
On the Android side of things, one way to do it would be to use TCP sockets. You can learn more about them here: http://developer.android.com/reference/java/net/Socket.html
I have been looking for a way to set up the Android SIP stack to be able to establish a SIP call between two devices on the same network, in an ad-hoc manner. i.e without REGISTERing to a SIP server.
I have not been able to get this to work, as the SIP Demo includes server registration, and I cannot get it to make or receive a call without this step.
I am not even sure if this is supposed to be possible. The little mention of this I have been able to find is conflicting (some say it can be done with a specific set up which they do not say what is, and some say the Android SIP API is not meant for this).
I was wondering if anyone has got this to work or has any clues as to how I could go about configuring the API for this, as I would like to use the built in SIP API before looking at third party ones.
The application I am developing is an internal one which will always be running on the same devices, so the fact that the SIP API is not present on all devices will not be an issue for me.
I have been stuck on the same problematic.
If you can make it without the android sip api, you can look at the rtp api which gives you a bit lower-level tools to make a P2P VOIP application without the need of a server.
To support audio conferencing and similar usages, you need to
instantiate two classes as endpoints for the stream:
AudioStream specifies a remote endpoint and consists of network
mapping and a configured AudioCodec. AudioGroup represents the local
endpoint for one or more AudioStreams. The AudioGroup mixes all the
AudioStreams and optionally interacts with the device speaker and the
microphone at the same time.
The counterpart is that you have to write your own device discovery protocol in order to know the port used by the audiostream peer as explained in this answer
The problem is not so hard if you only intend to make one-to-one conversation but is a little bit trickier if you want to make one-to-n conversation.
For a one-to-n conversation, the conference host has to instanciate n audiostream for each remote device he wants to call. Each remote peer has only one audiostream linked to one of the host audiostream.
You can do this with CSipSimple, which is open source: http://code.google.com/p/csipsimple/
You set up local accounts, register to yourself instead of a server, then make a phone call using TXT mode and dial remote_account_name#remote_ip_address.
Sip peer is like an extension number used to configure in sip phone . Please find details for creating sip peer . I am using centos 6.9 64 bit and having installed asterisk 11
You can create sip peer using asterisk server .
Goto vi /etc/asterisk/sip.conf
[1001]
username=1001
secret=123
qualify=yes
type=friend
disallow=all
allow=ulaw,alaw,gsm
host=dynamic
For more detail and easy understanding. Please refer given below link
https://youtu.be/27wm-fu25SM
or
http://rulariteducation.blogspot.in/2017/07/how-to-add-sip-peer-in-asterisk.html
I downloaded the open source code of webRtc.In side that I found the WEbRTCDemo test project for Android.I am able to generate the APK BUt when I install it my device not Able to communicate with both device....
Steps What I am doing..
1. In application settings->HostId: I puted Ip Address of other Android device and pressing the start call button but problem is in another Side Nothing happening.
My question is
1.for communicating the with other Device I have to setUp any server??
2.Can any one explain how its working in case of Android Device.
Please help me.
Thank You
Krishna.
Yes, you most definitely do need a 'messaging server'. Your task here is to relay the SDP from one client to the other. The SDP includes the ICE Candidates, which basically tells a client how to directly 'reach' the other (IP Address + Port combination). Once both the clients have exchanged these 'handshake' signals, they can start transferring their streams peer to peer.
Now, the implementation of this server is completely left to you. Since it is decoupled from the rest of the WebRTC API, so you can safely resort to any technology to make sure that these signalling messages are exchanged between the two clients. And once you have successfully established a PeerConnection, you can from there on even use the DataChannels to re-negotiate.
To sum things up,
Yes you do need a server to relay the messages between two clients.
Since this is independent of the WebRTC implementation, you can resort to any technology of your choice.