I am making a web-system for a callcenter, where I need an integration to SIP (so I can call phonenumbers).
I found this tool that looks like it's suitable as a softphone. https://www.doubango.org/sipml5/call.htm?svn=170
I have made an test account at sipdiscount.com (it looked cheap) that I suppose, I can connect to doubango's softphone tool. But how do I connect? What is private/public identity? And do you have any better suggestions?
To connect to a SIP Proxy (UAS) you only need Host Name or IP Address AND username/password. Also, online SIP providers typically give your a Trunk, which can be used telephone number to dial-out and/or accept new calls. However, SIP provides provide trunks and allow you to define your own telephone numbers, which route through the SIP trunk. Default UDP port is 5060. For security purposes, some SIP providers provide SSL\TLS over TCP port 5061, while others support DTLS over UDP port 5061.
private/public identity is not part of SIP protocol, so might be some proprietary doubango thing. I never used doubango, so not sure. I've been using Zoiper, which is the most basic SIP Phone and a UI that is common to all softphones.
Related
I am developing STUN for VoIP behind NAT(SIP protocol)..
I have a couple of routers for use..I find that the routers are changing the SIP messages(SDP and contact field)for NAT traversal...If I disable SIP ALG in routers,then NO SIP packets are forwarded..Is there any setting so that the Routers don't put any SIP intelligence and just forward the packets and not change the sip packet.
Thanks and regards
Buy a new router. Seriously, any NAT existing in 2013 that is still trying to translate application protocols (other than FTP) and modifying message contents (beyond the IP header) should be thrown out.
Is your SIP traffic sent over TCP or UDP? Is there a SIP gateway involved? Or are you trying to do a SIP INVITE between two endpoints without a signaling server?
In any case.... the standard solution to this problem is that the SIP messages should be sent over TLS/SSL (encrypted) to the SIP gateway. Your router won't be able to interpret these messages and will just treat them as a standard TCP traffic.
If you code for both endpoints, a simpler fix is to simply base64 encode your messages
Does anyone know if there's a way to do IP spoofing in an ios/objectiveC/iphone app? I looked online, but couldn't find any way to do this. A few apps on the app store claim to be able to do this, but there is no indication anywhere as to how.
In order to modify an IP header, you need access to what's known as "raw sockets". Raw sockets aren't allowed on most operating system without elevated privileges.
Unfortunately for you, iOS apps don't run with the required privilege for raw sockets. You might be able to do something like this from the simulator running as root, using low level C sockets:
int sockfd = socket(AF_INET, SOCK_RAW, 0);
But you'll get an error if you try to run this on an iOS device (not jailbroken).
Spoofing an IP address has very limited use anyway. When you send data to a server from a spoofed IP address, you never see the response. Using a spoofed IP address, you'll never be able to establish any connection that requires any kind of handshake, including TCP and VPN connections.
About the best use of a spoofed IP address is to perform some kind of denial of service (DOS) attack, hiding your actual attack origin. You could perform a SYN flood, or you could flood UDP services such as DNS. However, you couldn't use it to post to a web server because HTTP requires a TCP connection.
More and more networks are getting smart and not forwarding traffic that doesn't originate from their network, so as time passes, these kinds of attacks will become less practical.
What is the purpose for using sip with VOIP ? is it just to know the remote ip address ?
If i know (by server) the remote IP address ,then established a direct TCP socket connection for call negotiation, and send the media over RTP protocol ,so am i still need sip protocol ? or how can sip help me here?
The Session Initiation Protocol does rather a lot more than find out a remote IP address/port/transport triple.
It lets two parties
negotiate the media streams (including codecs and transports) and
establish commonly understood extensions to the protocol.
It also describes how to build scalable infrastructure (proxies, using SRV and NAPTR records, back to back user agents), location services and a host of other details that go into making a voice (or any other kind of) call to arbitrary third parties.
then you have implemented a sip alternative. sip (session instanciation protocol) does just control the "phone call". if you want to do that on your own, why not? the only problem would be that there are many sip clients and just one (or few) clients using your protocol.
SIP allocates a IP:port to a voip call. The RTP flows (one for each direction) will then use this IP:port as a destination address. If you have only one static RTP flow to send to your server, it may be useful and ok to do what you said.
Otherwise, if there are many clients, or if your system has to change a lot, it's better to use a polished protocol which will dynamically allocate ports and establish your sessions.
nobody forces you to implement a standard.
e.g. why do you implement the media stream in RTP? most likely because you already have code that "talks" RTP (e.g. a library, or a raedymade application).
the nice thing about standards is, that it will work "out-of-the-box" with all other applications implementing the same standard.
if it is an open standard, there's another nice thing: other people have already spent a lot of brain power into getting the implementation right. you don't need to fall into the same problems.
I'm in the process of trying to write a chat application and I have a few issues
that I trying to work out. The application is basically a chat application that works on a Lan. One client acts as the
host and other clients can connect to the host and publicly chat among themselves. I want also the option of a client starting
a private chat with an already connected client. So what is the best way for this to happen. For example should the request message (which
contains the ip address of client) route through the host and then if the requested client wants to connect , then they initiate the connection
using ip of the requesting client. Should this also be on a separate port number. Does it matter if your application uses a number of ports.
Or, when ever a client connects to a host, the host should send them a list of users with there ip addresses, and then the client can
attempt a connection with the other client for a private chat.
Hope this all makes sense. Any help would be appreciated
Thanks
If you are just interested in a quick-and-dirty chat facility that only needs to work over a LAN, I'd suggest having all clients send and receive broadcast UDP packets on a single well-known port number. Then no server is necessary at all, and thus no discovery is necessary either, and things are a lot simpler.
If you really want to go the client-server route, though, you should have your server (aka host) machine accept TCP connections on a single well-known port, and then have it use select() or poll() to multiplex the incoming TCP connections and forward any data that comes in from each incoming TCP socket to all of the others sockets. Clients can connect via TCP to the server at this well-known port, but the clients will have to have some way of knowing what IP address to connect to... either from having the user type in the IP address of the server, or by some discovery mechanism (broadcast UDP packets could be used to implement that). This way is a lot more work though.
I'm all for creating my own but depending on time constraints sometimes I look for alternatives like this I used it in a company I worked at before. It's really good. But if you decide to make your own you first have to map out a logic, structure, Database and so on before you even think about code..
I'm trying to understand the exact problem with NAT and SIP and have seen many different explanations. Here's what I've gathered so far:
1) SIP User agent is both initiating and accepting calls, therefore unless the NAT/firewall is configured to accept incoming traffic on this port it cannot work - this makes sense but sounds more firewall and port mapping
2) SIP messages contain IP addresses (that can be private) in the body which requires NAT traversal - if this is the case
3) it's not a problem with SIP but with RTP, whose parameters that are included in the SDP as part of the SIP message body that include private IP addresses
4) something to do with UDP vs. TCP?
When a call is done with SIP the calling endpoing does not know the endpoint the call must reach i.e. the endpoint's IP.
It only knows the IP address of the SIP server.
So the INVITE goes to the SIP server and SIP servers "knows" where/how to reach the called endpoints.
The idea is that the SIP messages contain SDP data that contain the information needed so that eventually the phones will be able to set up a session and users will be able to start talking.
These data include IP, port, codecs and other parameters.
So if one of the phones is behind NAT the phone will report as its IP e.g. IP_X which is its private IP and the other endpoint can not reach that IP; the public IP is unknown at that point.
All of your assumptions are correct.
In SIP, you can split it into 2 main problems: signaling and media.
The signaling runs in SIP over either TCP or UDP, and the connection can open from both directions, as calls can be dialed or accepted by user agents.
The media runs over RTP (and RTCP), which is usually done over UDP (unless you're trying to achieve NAT traversal), and then it might go over TCP). The ports and addresses here are allocated dynamically, need to go both ways and run on multiple sessions (=multiple sockets and connections).
To achieve NAT traversal, you will usually use multiple techniques: STUN, TURN, ICE, HTTP tunneling and even an SBC.
NAT traversal for SIP requires external support from servers - usually not the SIP server - that are dedicated for the job.
I'll disagree mildly with Tsahi Levent-Levi's answer.
The problem is that the IP address you put in your Via, Contact, From/To headers, SDP, etc., must be globally routable. If you're behind a NAT you'll obviously need to put in your external IP address.
Implementing ICE, using STUN, etc., allows you to do this automatically, but you can always solve the program manually.
In particular, by inspecting your machine's routing table you can tell whether or not the machine you're calling is behind a NAT or not (by virtue of knowing that work machines are behind this VPN NAT here, and local machines are on this subnet, and everything else runs through your router's NAT). With that information you may find out a NAT's far-side/external address somehow (STUN gives this automatically, but your internet router may have a static address, or you could contact an HTTP server capable of returning your external address, or ...). Once you have that far-side/external address, you can put the address where necessary - your Contact header, SDP c= headers, and the like.
There is a whitepaper by Eyeball Networks that clearly explains the NAT & firewall traversal problem for voip and the STUN, TURN, ICE solution. There are also a couple of great diagrams on how SIP P2P and SIP TURN calls are achieved at http://www.eyeball.com/voip-solutions/stun-turn-ice.htm