For a while now I've been playing around with the SipDemo in the Android 2.3
SDK.
The documentation on Android's developer page is nicely written, but it's
not a lot. It does not explain anything about IPs, ports, NAT and STUN.
I know how this stuff is supposed to work, but it doesn't say how
Android's SIP API handles it. Or does it handle NATs at all...
Here, someone mentioned that the API does do some tests for public IP
and port, but it's the first time I read it:
http://code.google.com/p/android/issues/detail?id=14043&can=1&q=sip%20ip&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars
So I'm not sure this is true. At least for me, it didn't work.
But now to my problem:
When I deploy the SipDemo as-is either to my device connected to WiFi
or to the emulator, provide my credentials (I know they work with
SipDroid and other SIP apps) the SipDemo displays "registration
failed".
I did some sniffing and found out the packets sent to the SipServer
all include the devices or emulators local IP, not my NAT's public
one. Something like Via: SIP/2.0/UDP 192.168.0.106:53230
The server replies correctly that RFC1918 IPs are not allowed.
I added a STUN test to the SipDemo and successfully retrieved my
public IP and port. But I can't find a way how to pass it on to my
created SipProfile or the SipManager.
My question:
Has anyone ever made an application working with the SIP API behind a
NAT?
How does the API handle NATs? How can I pass the information I got
from my own STUN client to the SIP API?
I know SipDroid and a lot of other SIP implementations, but they
all do not use the built-in API.
I added a STUN test to the SipDemo and successfully retrieved my
public IP and port. But I can't find a way how to pass it on to my
created SipProfile or the SipManager.
If you are behind symmetric NAT it doesn't matter, because a new NAT binding will be created for the outbound SIP connection, so the information you gathered with STUN is not really usable.
You shouldn't bother about NAT from a SIP API, the server needs to implement NAT traversal techniques for you.
There are cases in which you can actually do something from the client: when ICE is being used and you choose your own TURN server, but I don't think Android implements ICE and TRUN support yet. Even if it would, you'd still need to deploy a TRUN server...
Free services out there do implement NAT traversal techniques, you may try http://sip2sip.info for instance.
Related
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/
I have to setup a secured sip session between android phones on 3G network. SIP signaling would be secured with TLS and media stream with SRTP. And I have never touched these protocols and components required to accomplish this.
I want to test it first with a LAN setup, for that I am trying to setup following with latest versions so that I don't miss on some security features:
Asterisk (+ Dahdi + LibPre)
Apache
MySQL
FreePBX
Sipdroid on Android.
But for reducing variables I am going to test it on two PCs with some minimalistic SIP UAs and without any secure protocols. Just to make sure that asterisk is running fine.
I have Ubuntu 10.04 running on Parallels Desktop on MacBook Pro.
Problems
What are the components needed to make this happen, meaning do I need FreePBX for Lan based call is Asterisk is not a PBX?
I have read "asterisk to asterisk" calling. Is it a SIP UA as well, I have also read that it will act as a SIP Server.
Some link where I can get myself educated to set up the environment.
Is running that on virtual machine going to work. I have tested apache and its working from another PC in my LAN.
Thanking in advance for your support.
Such setup will be too complex for beginner to be stable.
Better option(and more secure) use openvpn.org tunnel and not use TLS.
1) Freepbx is just web for simpler control asterisk. I not recomend use freepbx for public systems(for internal use it ok if firewalled). You also need add fail2ban to your installation.
3) http://www.asteriskdocs.org/, http://cdn.oreilly.com/books/9780596510480.pdf. But i am afraid you will need some REAL experience to got working what you requested.
4)Dahdi on virtual machine will not work. Conference will not work. Sound can have issues. All other would work ok.
I want to develop a client server application in which server is on PC having wifi and client application in on android phone. I want to make server application using vc++.Net and client application in android. I am newbie in network programming and i am unable to find any clue about this on internet. And I also don't know is it possible that server is made using vc++.net and client is made using android.
Can anybody please direct me how can i move for this. And if possible please provide me some links related to this.
Any help will be appreciated.
Your question is vague and open to a lot of potentially "correct" answers. First of all, the whole wifi v.s. internet part is irrelevant, you just want to communicate from your Android devices to your pc over the network.
The term to look for is sockets. What you do is listen to particular port on the PC (the "server"). You'll have to open up the relevant ports in the firewall.
You then write an android app that communicates with this server, see here for a proper introduction.
There is no problem using a single socket (ip address + port) to connect with multiple devices, as long as your protocol includes a way for each client to identify itself.
...
That said, you can also do all of this at a higher level, running a SOAP/JSON-based client/server scheme (as opposed to writing your own socket-based protocol). See http://wiebe-elsinga.com/blog/?p=405 for an example.
What is the most appropriate choice depends on your exact requirements (performance, deployment) and your level of experience.
Update
You can use jmDNS to achieve this. It's a really helpful library and once you detect the all devices connected to the same wifi you can get their ip and port so you can establish a connection. You can learn more about how to use it here.
Or you can use Android Wi-Fi Direct API which works only for API Level 14+. Here is more information about the API : Wifi-Direct.
how to achieve transfer file between client and server using java socket
Hope it is what you are looking for! : )
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 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.