I'm looking to rebuild an existing VOIP app for android and iphone because it has poor call quality. I would like to replace my SIP library with the same one that Skype uses.
Does anyone know which SIP library Skype uses? Is it an open source one? Is it something proprietary that they built? Is it commercially available?
Skype has a proprietary signalling protocol and the code is not available. A lot of articles have been written about the subject. Here you have an example.
Skype performs the signalling over several ports and protocols and it can even send it encapsulated inside HTTP protocol so that it can still work on limited networks. I don't know what made you say that Skype uses SIP, but I don't think that it is used. I believe it is a small proprietary protocol and you can find some evidences for this in several articles where packets were analyzed.
Skype doesn't use SIP. Skype had other issues to deal with that SIP doesn't handle well. For example, SIP doesn't like NAT very much and several hacks must be used to get around it as best as one can. Skype, at least before the Microsoft era, used a proprietary protocol peer-to-peer (remember what Skype USED to make :-) ), and had the concept of Supernodes. Supernodes were other Skype nodes that had public IP addresses. Skype nodes would attempt to do a peer-to-peer call, but, in the event things like NAT and firewalls got in the way, they could relay their conversations from a Supernode. Again. who knows what they do now that Microsoft has been in the code. We know that Microsoft does inspect their messages.
What is the issue with SIP? If it's that NAT traversal issue - there are variants of protocols such as IAX where all traffic goes over a single stream, avoiding the SIP media problem.
Related
I'm looking for the name of a protocol and example code that permits handing off IP/port connections to establish unmediated P2P after introduction through a server.
Simple example:
You and I both start chat programs that connect to chatintroduce.com (fictional server). I send you a "Hi! Wanna chat?" message. It doesn't get sent. Instead my chat program tells chatintroduce to send your chat program a request for connection. You respond to a prompt and your chat program tells chatintroduce to broker the connection. Chatintroduce establishes an initial two-way connection between us. Now, this final step is important, chatintroduce releases control and our two chat programs now talk directly to each other without any traffic through chatintroduce.
In other words, I construct packets which have your IP address and you receive them without interference from firewalls, NATs or any other technologies. In other words, true peer-to-peer connection independent of intermediate server.
I need to know what search terms to use to find appropriate technology. An RFC name would suffice. I've been searching for days without success.
I think what you are looking for is TCP/UDP hole punching which typically coordinates the P2P connection using a STUN server to determine the "capabilities" of the firewalls (e.g. is it a full cone nat? symmetric?).
https://en.wikipedia.org/wiki/Hole_punching_(networking)
We employed this at a company I worked for to create a kind of BitTorrent that could circumvent firewalls for streaming video between two peers.
Note that sometimes it is NOT possible to establish a connection without the intermediary.
What you are looking for is ICE protocol. RFC 5245. This protocol is used for connecting two peers through NAT traversal. There are some open source libraries and also some proprietary libraries for this. You can search google with ICE implementation.
You will also need to read about some additional protocols. These are used with ICE protocol. They are STUN and TURN.
For some cases you can't make P2P call 100% time. You will have to use a relay server. Like if the NAT combination of two peers are Symmetric vs Symmetric/PRC. That relay server is called TURN server.
Some technique like Port forwarding and TCP/UDP hole punching will help you to increase P2P rates.
See this answer for more information about which combination of NAT will require a relay server and which don't.
Thank you. I will be looking further into ICE, STUN, TURN, and hole-punching.
I also found n2n which looks like almost exactly what I wanted.
https://github.com/meyerd/n2n
http://xmodulo.com/configure-peer-to-peer-vpn-linux.html
With n2n, one makes a VPN with a super node that all other edge nodes know.
But once the introductions are made, the super node can be absent.
This was exactly what I wanted. I hope it works across platforms (linux, MacOS, Windows).
Again, I am still researching before implementation, so your advice was very important to me.
Thank you.
Use PJNATH. Its open source.
http://www.pjsip.org/pjnath/docs/html/
There is not much open source on NAT Traversal. As far as I know PJNATH is good.
For server you can use Google's Open source STUN and TURN server.
I want to setup a personal videoconferencing service for my family, friends and myself. The main problem I have with current options is that they are either closed-source and centralized (GG hangouts, skype) or open-source but not working in corporate environment or in hotels (due to strict firewalling rules and the "Skype is going through, if you want VOIP use that" kind of netadmin reaction).
I have two solutions then. Either setup a STUN/TURN relay server and use XMPP and SIP as I used to, but that would require my friends to setup that too. Or setup a whole VOIP server. 2 solutions come to mind: SIP and XMPP. Though to my knowledge, each of them ultimately uses the (S)RTP/RTCP protocol.
And that's the problem. Out of the specific signaling part used by the two of them, I really can't figure out the difference between them, their typical use case.
I think you're right in that as far as setting up a video conferencing system XMPP and SIP are equivalent. They both are signalling only protocols and the media sessions they set up typically use RTP (although they can both be used to set up any kind of session you want but RTP is the norm).
The biggest problem is also going to be the one you mention about getting video streams out of a corporate firewall. Skype overcomes this obstacle by sending it's media over an SSL connection and is thus able to get through firewalls. Theoretically you could do the same with RTP and in the past I once used openvpn connections with a SIP client to test some audio calls. My experience wasn't great as the audio was very choppy, assumedly as a result of all the extra packaging that is required to get the high volume of small audio packets from one end to the other. That was nearly a decade ago though so perhaps with the better CPU and bandwidth resources available now it would work better.
Personally I think I'd stick with Skype as it's going to be a big hassle to set up your own system. If you were to go ahead with your own the first option I would try would be Asterisk combined with openvpn so that if the clients were behind a firewall or had NAT issues they could connect over it.
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.
At the bottom, it's all about socket communications. If there is some way to get the ip of the both users, why can't the connection be directly setup between the users instead of having to go thru a server in the middle?
My 2 cents:
No one out there forces us to have a server based real-time communication model. Infact XMPP have an extension called "Serverless Messaging" which defines how to communicate over local or wide-area networks using the principles of zero-configuration networking for endpoint discovery and the syntax of XML streams and XMPP messaging for real-time communication. This method uses DNS-based Service Discovery and Multicast DNS to discover entities that support the protocol, including their IP addresses and preferred ports.
P2P chat applications have been for over a decade now. Having a server in the middle is purely a decision dependent upon your application needs. If your application can live with chats getting lost while the user was transitioning between online/offline status, then you can very well have a direct P2P model going. Similarly, there are a loads and loads of advantages (contact list management, avatars, entity discovery, presence authorization, offline messages, ....) when it comes to choosing a server based messaging model. If you try to have all this right inside your P2P based clients, they might die or under-perform because of all the work they will need to perform by themselves.
"WebSockets" were not designed for P2P/Serverless communication, rather they were designed to provide a standardized PUSH semantic over stateless HTTP protocol. In short, "WebSockets" is a standardized way replacing hacky comet, long-polling, chunked-encoding, jsonp, iframe-based and various other technique developers have been using to simulate server push over HTTP.
Named WebSockets (if someday it is fully and widely supported) could be the solution.
http://namedwebsockets.github.io/spec/
Named WebSockets are useful in a variety of collaborative local device
and local network scenarios: Discover matching peer services on the
local device and/or the local network.
Direct communication between users is possible in Peer To Peer (P2P) networks. In P2P each participant can act as client as well as server. But for P2P networks you need to write a separate program to make the communication possible.
Web Sockets let you leverage existing common browsers as clients. All depends on what is the purpose of your application and how you want to deploy it.
If there is some way to get the ip of the both users
You nailed the answer right in your question.
Most machines I use have IP address of 192.168.0.10 (or similar from 192.168. private network) and are deep, deep behind several layers of NAT. With the end of free IPv4 address pool and IPv6 nowhere near sight, this is the reality most users live. Having a stable intermediary of known, routable address helps a ton working around this issue.
WebSockets don't allow the socket to listen for connections, only to connect as a client to a server (not reverse). Technically they could make it allow this, but as far as I understand the spec doesn't currently (nor is it expected to) allow listen functionality for WebSockets.
The new WebRTC (http://www.webrtc.org/) spec looks like it might support peer-to-peer connections. I have not played with WebRTC at all so I'm not in a position to comment on it. I think it would be a bit more involved than WebSocket stuff. Maybe someone who knows WebRTC better can chime in. (Also apart from the latest version of Chrome I'm not sure if any of the other browsers really support WebRTC yet).
I am working on a project of P2P instant messenger, like ichat, but just for LAN.
I use jmdns library for service discovering, and test with pidgin and log in as a Bonjour user. as so far,the service _presence._tcp.local. is well discovered,
then we know the user's information in LAN like name#host:port, so how to start a conversation with Bonjour client ?
I looked into XMPP, but it do not support P2P, but I can hardly find the library for the extension jingle which supports P2P.
maybe I should use SIP to make a conversation? but the packet format is compatible with Bonjour ? or I have to study the structure of packet exchanged?
Can anyone explain a little about how does ichat work for LAN?
Many thanks for your kind help！
I think you're a little confused.
Bonjour is a mechanism for finding a service. It is not for communicating with a service. Once you have found the name#host:port information, you are finished with Bonjour.
The next step will require you to talk a protocol that the service understands. The token _presence in the service string indicates that this is an XMPP service. You will need to talk XMPP to it. You cannot talk SIP to it. Have you tried opening an XMPP connection to the host and port you have found?
You talk about SIP and Jingle. These are used to set up an audio or video call. If you are writing an instant messaging program, you do not need to do this. XMPP alone is enough.
If you do want to support audio or video, then you will need one of those protocols. Because the service you have found is an XMPP service, you will need to use Jingle. If you don't have a library that can speak Jingle, you will have to write the code yourself. There is nothing in the Bonjour information that identifies a SIP service, so you cannot use SIP - unless you can make a different Bonjour query and find a SIP service.
I infer that you are working in Java. The most popular XMPP library for Java seems to be Smack.
Thanks for everybody's attention, now I have found something. XMPP doesn't support P2P mode, only supports clients-server-clients. but there is another standard "XEP-0174: Serverless Messaging" which is right for p2p chat in local network. DNS-SD + XEP-0174 , ichat works in this way.
as I used smack library, it do not support p2P; but someone did some changes, here is the link
http://issues.igniterealtime.org/browse/SMACK-262 .
I didn't try this XMPPLLConnection, I have looked into the source code of smack, it is based on socket connection. unfortunately there is not any java library for XEP-1074, so I have to work on xml stream over socket.
You may use SIP for that. MDNS will be your discovery mechanism, then you'd use plain SIP for calling, one you learned the URI you wish to dial.
SIPSIMPLE SDK (http://sipsimpleclient.com) implements this feature by sing this expired draft: https://datatracker.ietf.org/doc/html/draft-lee-sip-dns-sd-uri-03 it could be a good start.
Basically your client would generate a URI like sip:random_stuff#ip:port and then publish it along with a display name by using MDNS. The application also browses MDNS for peers on the LAN: _sipuri._udp for example. Once you get some URI you can just dial using SIP.