Hello! Please, help me. I have troubles with SIP on Whonix.
Using Linphone client.
I can connect to my sip-provider, and calls working ok - I can make outgoing and accept incoming
calls.
But in dialogue I can’t hear anything, and my friend don’t hears me.
Microphone and headphones are working in Whonix.
I think troubles in network.
Using TCP (with UDP I can’t connect to server).
Sorry for bad english.
Please next time use a search engine, because if you search for “Whonix
linphone” or “Whonix voip”, you would find this:
Thanks. I read that article few times, it doesnt’ helps me 
Haven’t tried in a while…
Not Whonix-specific issue - most likely your issue is SIP (RTP) over NAT:
This sounds interesting:
Linux kernel: Netfilter seems to have got a conntrack patch for sip/rtp nat/firewall traversal: Iptables sip conntrack
It would have to be on every NAT server though. Good luck!
Did you follow the detailed linphone instructions in the Whonix wiki step by step with onioncat and whatnot?
OP wasn’t specific but description sounds like he’s trying to VOIP to a PSTN-connected SIP service provider (for calls to real phone numbers) and not voip-client to voip-client. So OnionCat is not applicable.
You can’t connect via UDP because Tor doesn’t support it.
TCP doesn’t work because all major SIP providers require UDP.
But even if you tunnnel UDP over a VPN as I’ve tried, it still won’t work.
Problem isn’t SIP protocol. You can connect, even transfer DTMF tones. But you won’t get any audio because that’s transferred over RTP. RTP ports are not hard defined so you can’t forward ports through your vpn (if that’s necessary - might not be). And to be technical, it’s a dumb protocol (IIUC) and doesn’t route very smoothly.
If you’re willing to take some risks and/or spend some money, try Skype ( Voice over IP (VoIP) ). Haven’t tested but apparently it’s like a gopher when it comes to finding it’s way through firewalls. IIRC even Google Voice needs UDP. Just brainstorming, you could put linphone on a vps and route from there - but now we’re really reaching. Lots of easier, safer ways to communicate.
Really not a useful issue to solve but I can’t seem to let go cause it should be doable…
Best description and tips here: NAT (Network Address Translation) - VoIP-Info
The Trouble with NAT and VOIP
In addition, the way in which conventional VoIP protocols are designed is also posing a problem to VoIP traffic passing through NAT. Conventional VoIP protocols only deal with the signalling of a telephone connection. The audio traffic is handled by another protocol and to make matters worse, the port on which the audio traffic is sent is random. The NAT router may be able to handle the signalling traffic, but it has no way of knowing that the audio traffic is related to the signalling and should hence be passed to the same device the signalling traffic is passed to. As a result, the audio traffic is not translated properly between the address spaces.
At first, for both the calling and the called party everything will appear just fine. The called party will see the calling party’s Caller ID and the telephone will ring while the calling party will hear a ringing feedback tone at the other end. When the called party picks up the telephone, both the ringing and the associated ringing feedback tone at the other end will stop as one would expect. However, the calling party will not hear the called party (one way audio) and the called party may not hear the calling party either (no audio).
The issue of NAT Traversal is a major problem for the widespread deployment of VOIP. Yet, the issue is non-trivial and there are no simple solutions.
If you cannot avoid NAT, use IP Tunneling between VoIP devices on different LANs
Whonix wiki method via OnionCat.
Set up two forwarding entries the “Port Forwarding” (or similar) configuration form on the NAT configuration interface, each of which cause the NAT device to forward all traffic destined for the designated range of port numbers to the fixed IP address of the SIP phone:
SIP signaling: Ports 5060 to 5070
RTP audio: Ports 8766 to 35000
The challenge for Tor users is being able to tunnel UDP + forward all those ports. Obviously, public VPN is not going to work.
2 Options,
Not gonna test but marking it [solved] 