Encryption is not illegal in the U.S.
Why doesn't someone create an open source encryption solution which encrypts the conversation with a public key prior to routing it over Skype then decrypts on the other end with the private key. I know encrypted land line phones exist i've seen and used one, any intercept or wire tap just gets something similar modem sounds. Their major disadvantage is the encryption key has to be set in advance of the call usually by sneaker net. When someone listens in, warrant or not all they get is nonsense. A truecrypt for VOIP.

If its not possible than we may see the return of the land line for secure conversations.

I would have to disagree. I can insure that my communication is not tapped between me and other parties even going through third parties. This is the basis of public key crypto. The third party can still track who I communicated with but not what was said. Tor and similar systems are meant to take care of that (if your seriously paranoid systems to connect two parties have existed since well before the modern computer).

I tried Jitsi like you did. I've been looking for an alternative to Skype for a while but could not find one.

I consider myself to have above-average knowledge of computers. However, compared to a pro, I'm just an average person.

I ran in the exact problem you describe: I figured out that while Jitsi lets me use many different services to log in with (e.g. msn, yahoo, etc.), the only really secure ones were SIP and XMPP.
The problem was, I couldn't figure out how to use these (what are they anyway? protocols?).

Reading your post, I now understand that I need to set up my own SIP server. I figured it would be something complex like this, but thanks to you I at least have a general idea of what I'm supposed to do. I'll never set one up on my own, just like I will never set up my own e-mail server even though I've been wanting to do so (so as not to have a third-party like hotmail store my e-mails).
I will ask a friend who works in IT if he can help me, but I'm pretty sure he will tell me that he's not familiar enough with SIP to help me out.

Bottom line, it's exactly as you said: a very good solution, but too impractical to use for the average person. I'm not entirely sure why it's so complicated in this day and age to cut out the middle men and connect with your relatives directly through the Internet, but well, that's the way it is at the moment.
And it's a shame really that protecting our privacy online, while still having access to all the useful technology the Internet enables, is so difficult to do for average people.

I'm looking forward to having e-mail and VoIP service companies setting up in Switzerland and promising to protect their user's privacy. That might be the most realistic solution.

Then check out his latest venture

https://silentcircle.com/

That is, immediately, a separate problem from one of them just spying on you for their own purposes, selling that information to other people or the like.

Wiretap (and intelligence) are lawfully chartered, you may not like it, but you have to accept that governments can do those things, because they've given themselves the right to. They also tell companies what they can't do, and penalize them for such behaviour if they are so inclined, an entity not attached to country where you have legal standing can basically do whatever the hell it wants to you and you can't do anything about it.

Googling for "Asterisk" is a pretty good place to start.

Largely you can blame NAT. Some background on how SIP works when you place a call to someone:
1. The calling phone sends a SIP message to the callee's phone asking it to ring. The SIP message also tells it where (ip address / port) to send the media (audio / video)
2. The callee's phone rings
3. The callee picks up
4. The callee's phone sends a SIP message to the caller's phone telling it that the call has been picked up. The SIP message tells it where (ip address/port) to send the media.
5. Both sides start sending media over RTP to the other, since they have now exchanged media destination address details.
6. The two parties have a conversation.
7. One of the parties hangs up
8. The hanging up phone sends a SIP message to the other phone telling it the call has terminated
9. Both sides stop sending media

This fundamentally does not require any middle-men - you can tell your phone to call someone else's directly if you know its IP address (which you could discover using DNS, for example). However, there are some issues with this simple view on things:
A. In the real world, phones don't have static IP addresses, they move around the internet. This problem is fixable with dynamic DNS, although now you've introduced a third party (the DNS server).
B. People usually have firewalls between them. If the callee's phone isn't directly accessible from the caller's network, the caller can't send the initial "ring" SIP message. This could be fixed by poking a hole in the firewall for port 5060. More usually its fixed by having a SIP registration server somewhere on the internet - your phone connects to that server and that server is responsible for relaying SIP messages to it. So calling phones actually send the SIP packet to the registration server rather than directly to the callee's phone (this also fixes problem (A) without the need to resort to dynamic DNS too, since the callers nw only need to find the registration server rather than the phone itself). Of course, your registration server is a "middle man", but luckilly only carries the signalling traffic - the media still goes directly between the phones, which is good since it takes the shortest network path, therefore inproving the quality of service.
C. This one is the killer - NAT. Remember the phones exchanged addresses to send the media to? Well, the problem is that once you stick NAT in the way, those addresses change... and they change in a way that is completely unpredictable. So now the endpoints have no idea where the hell to send the media. The work around to this is to send the media via a server too. And there you go, the dream of true peer-to-peer VoIP has been completely shot out of the sky.

Once IPv6 is widespread we can go back to just sending the signalling via external servers rather than the entire media stream, but I'm afraid NAT is way too widespread to get away with that on the IPv4 network.

Of course, there's nothing stopping the phones doing end-to-end encryption on the media, which would largely make the existence of a middle-man irrelevant, from a security perspective. On a closed system like Skype, there's no way to know which nodes are able to decrypt/decode the data though, so in that case you're always going to have to trust the vendor to tell you the truth instead of being able to independently confirm the security of the system.

I don't disagree with your comment, but..

I'd say it'd make it nearly impossible (without resorting to active attacks using malware and stuff like that). It uses no PKI, unlike HTTPS, and you can enforce and define which encryption methods to use (public cryptosystem, hash function, cipher). If you're worried about the NSA being able to break AES, you can run your conversations over AES+Blowfish+Serpent or something silly like that.

True, but in the case of Jitsi (and stuff like Pidgin-OTR), there are no "keys to be stolen", unless your device is already compromised during the session: it has perfect forward secrecy, which means that each session uses a random key which gets deleted at the end of the session, effectively preventing "rubber-hose cryptanalysis" of past conversations (assuming none of the endpoints is logging the conversations is cleartext or something).

Given this and the point above, Jitsi seems pretty good, and I'm not seeing how any type of automated eavesdropping could be done against it, as long as the two endpoints are "clean".