Hi I am using AppRTCDemo and its working on their server. How ever the current mechanism is for exchanging chat-rooms name and entering the same room connects the peers.
But I want to dial a call from one device to receive a call from other device and then peers should enter a room for video session ,
I have searched a lot , I have come up with for that I need signalling-server which I don't have and don't want to put hands on it ,
Now in this situation how can the other device know that device one is dialing and sharing particular room name to accept and enter the same room for video call at client side in Android .
https://github.com/njovy/AppRTCDemo
There are two android apk available for WebRTC, appRtcDemo and webRtcDemo. appRtcDemo apk can be used for android device to browser connectivity. You need to provide room id to connect to one room. If you are the room initiator then you have to enter -1.
If you want to connect two android device then you have to compile and install webRtcDemo apk. This apk interface provide place to enter ip address of another device and vice versa then both device will be connected.
Please go through -> http://www.webrtc.org/reference/getting-started
For more information. Both the apks i've compiled and installed and checked how it works.
I was able to make calls successfully between two android device using webrtcdemo. But I tested using WLAN of my office network. I did not use it further because I was using apprtcdemo for app reference. My suggestion is when you enter remote ip in webrtcdemo,just check if loop-back is unchecked. I guess for you loop-back is enabled, so you are receiving your own video packet, though you have entered remote ip. Make sure loop-back is disabled while making call.
A very good explanation can be found in this book http://chimera.labs.oreilly.com/books/1230000000545/ch03.html#STUN_TURN_ICE
which provides the fundamentals on how WebRTC uses ICE technology.
In particular assuming the IP address of the STUN server is known, the WebRTC application first sends a binding request to the STUN server. The STUN server replies with a response that contains the public IP address and port of the client as seen from the public network.
Now the application discovers its public IP and port tuple which can send to the other peer through SDP. (note that SDP are sent over an external signalling channel, f.i. websocket established through a web service)
With this mechanism in place, whenever two peers want to talk to each other over UDP, they can then use the established public IP and port tuples to exchange data.
Unfortunately, in some cases UDP may be blocked by a firewall. To address this issue, whenever STUN fails, we can use the Traversal Using Relays around NAT (TURN) protocol as a fallback, which can run over UDP and switch to TCP if all else fails.
WebRTC gives SDP Offer to the client JS app to send (however the JS app wants) to the other device, which uses that to generate an SDP Answer.
The trick is that the SDP includes ICE candidates (effectively "try to talk to me at this IP address and this port"). ICE works to punch open ports in the firewalls; though if both sides are symmetric NATs it won't be possible generally, and an alternative candidate (on a TURN server) can be used.
Once they're talking directly (or via TURN, which is effectively a packet-mirror), they can open a DTLS connection and use it to key the SRTP-DTLS media streams, and to send DataChannels over DTLS.
Edit:
Acronyms here: http://blog.1click.io/10-jargons-abbreviations-for-webrtc-fans/ for the rest, there is Google. Most of these are defined by the IETF (http://ietf.org/)
Edit 2:
Firefox and Chrome (and the spec) have moved to using "trickle" for ICE candidates, so the ICE candidates are generally added after-the-face to the PeerConnection and exchanged independently of the initial SDP (though you can wait until the initial candidates are ready before sending an offer, and bundle them together).
See https://webrtcglossary.com/trickle-ice/ and https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/
Related
just want to know is there any methods to allow 2 different apps to communicate. Both of the apps are installed on different devices as well. I had gone throught quite a lot of research, but seem that INTENT, BROADCAST RECEIVER failed to meet my scenario. INTENT, BROADCAST RECEIVER can be work if both of the apps installed on the same device.
Here i can say you can use to make your things work :-
Sockets are typically used to accomplish this between Android devices (or between any peer devices).
When two devices desire to interact, you configure one or both of them to "listen" for connections on a socket and accept a connection from the other when that happens (or you can have a dedicated client and server and the client always initiates the connections).
You can exchange messages after the link has been made.
Android client server socket applications come in a variety of forms, but one that I found handy was:
Example of Android Server/Client using Socket on the client side (and its companion server side blog article - link included in the client blog)
It should be noted that you might need to add your own "protocol" on top of this. For instance, if you are sending a file that is unknown in length without a special "end" character, you might want to add a byte (or several bytes to represent an int, long, etc.) at the beginning to indicate the length of the transmission so the receiving side can tell when it has received everything (or that it has not received everything in case of an error).
connecting via networks (such as most 3G/4G) that forbid inbound connections
Even though there is nothing theoretically blocking sockets from functioning in these situations, many mobile operators will not permit inbound socket connections in practise. You would also need to determine the mobile's public IP address, which is doable but adds complexity. Whether your solution will only ever operate on a single operator's network, you can test it out to see if it works; but, if it doesn't, you could discover that using a server in the "middle" is preferable and easier: Devices A and B establish connections with servers Device A "discovers" device B after requesting the addresses of connected devices from the server. Device A sends device B a message.
Actually, it indicates that the messages should be forwarded to device B while sending them to the server. Device B is informed by the server that a message is available for it (using some sort of message notification like Google Cloud Messaging for example, or simply by the devices polling regularly to see if they have any messages). Device B accesses the server and downloads the messages. The aforementioned will function on pretty much any network that permits internet connectivity. It does have the drawback of having a server, but for the majority of mobile networks, it is probably a necessary approach.
You make one app a server using ServerSocket.
You make the other app a client using a Socket.
With both devices in the same network the client can connect to the server knowing its local ip.
After connection established they can communicate.
Im creating an Android App in which the clients can call each other without using a SIP proxy (server).
I downloaded the CSipSimple, it has a "local" option in which the clients in a local network can call each other directly.
What if I am connected to the mobile network. If i know the public IP of the destination, can I call him direclty?
If you can suggest another applications that fulfill the mentioned requirements please do mention them.
thanks
Yes, you should be able to make direct call with almost all SIP clients. I am using mizudroid and works with that.
In this case, you just need to enter the full URI for the destination and not just the extension name.
So instead of calling to "john" you will have to enter
john#ipaddress:port
Example:
john#192.168.1.33:14321
Some sip clients might require to prefix all these with "sip:":
sip:john#192.168.1.33:14321
As you can see, the tricky part is to find out the correct port. SIP clients are using random local ports by default, but some of them allows you to set the port explicitly. (Don't be confused with the server sip signaling ports which is usually 5060 after the SIP standards.)
Also please note that the role of a sip registrar is exactly this: so you don't have to play finding out the peer's exact address as the server can handle this for you automatically.
Some sip clients might require to enter a sip server address in settings/login, however most of them allows you to use the softphone without any address entered or they have an option to specify serverless/local/registerless or you might just enter a fake address (then the softphone might display "register failed" but you should be able to make direct calls as i have described above)
I had the same issue with how to connect 2 android devices via VPN without PBX server.
So, after establishing a VPN connection we were using Linphone app
Just click settings and disable the random port.
If you need to call another device, just type sip:device_remote_IP_addres on the dial pad and click enter.
For example, sip:192.168.1.2
I have a simple app idea in my mind and I need to know how to connect from an Android application (client) to a Windows application (Delphi, server).
There is no need to be specific about the platform, I am familiar with networks in Delphi using winsock or Indy and I'm sure I will be able to figure out the appropriate mechanism in Android.
What I need to know is how to connect to a server (computer), which doesn't have its own public IP and is not in the same network as the client (one can be behind a local router, while the other might be connecting to the internet through 3G, for instance). This should be possible, as many programs work like that (remote desktop programs, TeamViewer, for instance: one computer is assigned an ID and using this ID other computer can connect to it.) I will not have access to the routers behind which the app will be running, so port forwarding is not an option.
I have a working network app, but that only works in LAN, so I'm guessing somewhat another approach is needed.
Thanks for answers
Many of the programs that work that way still use a server with a public IP. Each side of the client connections to the server to say "here I am". The public server can then shuffle data between the two clients.
That still leaves a lot of questions regarding the communication between the public server and each client - i.e. pull vs. push for taking data that was sent to the server and getting it back down to the second client.
You may want to read the specification for Copilot (originally named Project Aardvark). Joel Spolsky published the specification when the started the project. It talks about their use of a reflector service.
The Reflector
A Windows Service which we run on our servers, used to
allow any helper to help any victim even when both of them are behind
firewalls. Both helper and victim connect to the reflector. The
reflector checks that they are authorized and relays messages between
helper and victim until the paid-up time runs out
you could put an intermediate server which they can both route for "nat traversal".
otherwise you will have to put port forwarding on one of those computer's local router to allow incoming connections to be forwarded to the computer.
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.
I am developing a multi threaded client-server Android app in which both clients and the server are android phones( the server is not centrally located) and are located in the same network, under the control of one single router.
The server will start the application first. When the clients starts the app, they should get the IP address of the server phone automatically, so that when they click the address, they can be connected to the server.
Right now, I have made a provision that the server phone displays its IP address on the screen when the app starts running. When a client starts the app, it is provided with a text field in which the user can manually type the server's IP address and get connected to it.
Can anyone give me any pointers on how I can get the server's IP address to be displayed on the client phone automatically? Do I need a central database or something like that? I am new to android programming and don't really have any idea about this.
See if this is useful: Android IP address with java
You might want to think about implementing a UPnP solution. See this Universal Plug and Play as a starter then check the links at the end for relevant docs/references.
UPnP doesn't require devices to explicitly know the network details of other devices and instead they locate each other using a discovery protocol (SSDP).
One solution is to ping local IP range in a loop. Put a small timeout duration. It would be better if you run it in separate threads. If you get ping response, this would mean the server is available.