Linksys PAP2 audio issues only for incoming calls

[amaramrahul]

Hi,
I have been trying to figure out a solution to this problem for the past 10 hours but have so far been unsuccessful. Here is the problem.

I have configured my PAP2 adapter according to the voxalot PAP2 guide. I am able to make outgoing calls and everything works fine. But when someone calls my voxalot account via SIP Broker, I am unable to hear their voice though they can hear mine. Also if someone calls me directly using the SIP URI xxxx@eu.voxalot.com, audio is not heard both ways.

From what I've read on the forums, this mostly seems to be some NAT issue. But the strange part is that when I connect to the voxalot account either using X-lite (in Windows) or iSIP (in iPod Touch), there are no audio issues with incoming calls. Both the smartphone and the desktop PC are in the same LAN as the PAP2. Something advanced like MAC / IP based blocking cannot be the cause as my LAN is behind a simple ADSL router.

I have tried all possible configurations and yet am unsuccessful. Here are my current PAP2 settings:

SIP:
Handle VIA received: no
Handle VIA rport: no
Insert VIA received: no
Insert VIA rport: no
Substitute VIA Addr: yes
Send Resp To Src Port: yes
STUN Enable: yes
STUN Test Enable: no
STUN Server: stun.voxalot.com
NAT Keep Alive Intvl: 15

Line 1:
NAT Mapping Enable: yes
NAT Keep Alive Enable: yes
Make Call Without Reg: yes
Ans Call Without Reg: yes
Enable IP Dialing: yes

The remaining PAP2 settings are those whose are described in the voxalot PAP2 guide.

The interesting part is that previously I had set to port forward 5060 from the adsl router to my PAP2 device and then if someone called using the SIP URI xxxx@<public IP of router>, it worked without any sound issues.

I am thinking that there is some small configuration change I should do in PAP2 to resolve this issue. Any help would be really appreciated. Thanks.

[amaramrahul]

Some additional info. As I told, outgoing calls to other SIP URIs and landline phones (using a VoIP service provider I have configured in Voxalot) work fine. Test call to *600 also works fine. It is only the incoming calls which has sound issues .

[Ron]

Handle VIA received: yes
Handle VIA rport: yes
Insert VIA received: yes
Insert VIA rport: yes
Substitute VIA Addr: yes
Send Resp To Src Port: yes
STUN Enable: yes
STUN Test Enable: yes
STUN Server: stun.voxalot.com:3478


In your router, forward the PAP2's SIP ports (typically 5060-5061) and the PAP2's RTP ports (typically 16384-16482) to the PAP2's LAN IP address.

[amaramrahul]

Another small update. I upgraded firmware from 3.1.15 to 5.1.6 and the issue seems to still be there. Also I cannot port forward those ports. Moreover i dont think that should be necessary as x-lite had no issues. So if I am not port forwarding, should I still change the values to yes?

[amaramrahul]

Thanks for the response. As suggested I tried setting all to yes. Yet it did not work. Perhaps the port forwarding is mandatory but that is not an option for me. The question "why only PAP2 is giving me this problem while X-lite works?" still puzzles me.

[snvv]

You may try
STUN: 72.51.45.215:3478
or
stun.xten.com
or

stun.sipgate.net:10000

If that does not work try
Proxy: eu.voxalot.com
Outbound Proxy: eu.voxalot.com
Use Outbound Proxy: yes
Use OB Proxy In Dialog: yes

Regards
snvv

[bridonca]

I have run into this problem before with Voxalot, and other SIP providers. The problem is not with Voxalot, the problem is with your NAT router, and partially with your PAP2 in that it cannot handle NAT very well without clearly defined ports. If you have a router that does not suck, you need to manually forward the sip port like 5060 and a RTP port like 12000 from your router to the PAP2. The PAP2 also has to be configured for those ports. If your router sucks, get a new one, preferably one that can do DD-WRT.

I am not a big fan of STUN because it only works if your router is not junk. If you have a good router, then STUN is bit redundant and pointless.

Why do some VOIP providers like callcentric work? It is because their SIP software is able to use nasty hacks to get the incoming signal working, but even these VOIP providers end up being flaky eventually. The PAP2 needs certainty on the ports to use to work reliably. The RTP port is what deals with the audio, so make sure it is a unique one. I use port 12000 myself.

[amaramrahul]

Thanks a ton for the reply bridonca. I guess that explains a lot. Port forwarding is not an option for me. So I am thinking of configuring one line for incoming (callcentric) and another line for outgoing.

[amaramrahul]

Hi, I've just found out that by configuring Voipdiscount directly on my PAP2 device, I am able to receive incoming calls. There seems to be a problem with SIPBroker <-> Voipdiscount peering but nevertheless I can call my PAP2 using the SIP URI <userid>@sip.voipdiscount.com.

Also I was successful in setting up an IPKall account to forward calls to this URI and it is working fine.

I sincerely think if a companies like Voipdiscount and callcentric could do something about handling NAT issue (in PAP2), then so should Voxalot.

Anyway, for now I am happy that I can use the same line for outgoing as well as incoming. Thanks for all the responses.

[carlosalbffgomes]

Originally Posted by amaramrahul

[...]
I sincerely think if a companies like Voipdiscount and callcentric could do something about handling NAT issue (in PAP2), then so should Voxalot.
[...]

Voxalot does it. If you choose 'NAT SYM = YES", then Voxalot tries to handle with NAT that does not complains with standards. The problem is that 'junky' implementations are all around and it is impossible to handle with everything that may happen in this field. So, in some situation, Callcentric can work and Voxalot doesn't. In some other situation, Voxalot works and Callcentric doesn't. All these problems are the way internet is built and there is nothing anyone can do about it.
Your problem is with your modem/router that doesn't handle NAT the way it should do. There are many 'junky' implementations, and all of them are different. So the solution to these kind of problems are in finding some sort of configuration that works and not trying to put to work the 'ideal' solution you want to implement. If you want to learn the technical part, this is an excellent opportunity. If you are only trying to solve some kind of need, that opt by something that works for you with what you have. There are no miracles here that anyone can do it for you. These are the way things are.
Regards,