I have two end points registered to SS:
A: public IP, so no NAT involved.
B: through a VPN tunnel.
When A call out to B: no problem at all.
When B call out to A: A can hear B but B cannot hear A. This is the major problem and seems to be all SS's fault.
I've tried [ma=false] etc.
When B places a GoogleVoice call, no inbound audio.
When B call out through a service provider such as VoipDiscount, no problem.
All inbound calls to B are fine too.
VPN issues
Re: VPN issues
SIPSorcery does not get involved in the audio path. It does try to help with private IP addresses that are sometimes places in SIP INVITE requests by substituting them with the public IP address the request originated from. If you think that's causing the problem you can do as you have tried and turn it off with the ma=false option.
Apart from that my advice would be to read some helpful articles on audio issues with VoIP and try the suggestions mentioned.
http://think-like-a-computer.com/2011/0 ... udio-voip/
http://www.sipsorcery.com/mainsite/Help/SIPAudio
Apart from that my advice would be to read some helpful articles on audio issues with VoIP and try the suggestions mentioned.
http://think-like-a-computer.com/2011/0 ... udio-voip/
http://www.sipsorcery.com/mainsite/Help/SIPAudio
Re: VPN issues
I know SS does not involve in audio path, that's all the reason I use it in the first place!
For the B to A call, I have to use the callback function:
sys.Callback("A", "B")
then all fine. If I use:
sys.Dial("A")
then no inbound audio on B.
There must be a bug somewhere in SS to cause such a difference.
For the B to A call, I have to use the callback function:
sys.Callback("A", "B")
then all fine. If I use:
sys.Dial("A")
then no inbound audio on B.
There must be a bug somewhere in SS to cause such a difference.