Inbound calls problem
 

Voxalot, please fix the issue.

I have had this problem for two days.
Three Linksys 3102 devices located in different places and registered to three different Voxalot accounts have the same problem: all inbound calls which are set up to go to My Voxalot Number end up in the voicemail.

You must have changed something on your side since I changed nothing lately.

Please have a look into that.
Thanks

I noticed that calling between Voxalot accounts takes extremely long, in my case they need at least 20 seconds to reach each other. And when they do, the voicemail picks up, regardless of the CF settings.

Which server are you pointing these devices to?

All of them are registered with us.voxalot.com

Maybe you configured each ATA to all use the same STUN server and that server is down, and that's how they're all down at once.

Other servers are listed here: STUN - voip-info.org

No, the STUN server is OK, I tried a different provider (Vbuzzer) and it works fine.
Voxalot must have changed something lately, it has to do with how calls are being treated while set to go to My Voxalot number.

Are any of those SPA3102 units able to receive calls within the first 60 seconds after registration? It may help if you test for that and post results here.

There are two methods for maintaining a NAT route through the router to the SPA3102, needed so the SPA3102 can receive calls. The methods are port forwarding, or sending NAT-keep-alive packets. Which method do you use in your routers?

If you are using port forwarding I can check that your SPA3102 units are reachable. Just send me the public IP address, 'User ID' and 'SIP Port' of the lines to be tested. I can do the test without ringing your phone, or I can make a SIP call and check the SDP packet at the same time.

These SPA3102 have worked fine for many months without any incidents.
Something have changed lately but I did not change anything.

Would stun.xten.com be faulty all of a sudden ?
I will have to test...

Probably not. Even if the stun server is not working the ATA could still be contacted and would still ring the attached phone. The call could be answered, however the audio may be missing in one direction, the person speaking on the ATA with the faulty stun server might not be heard by the other person.

Sometimes its preferable to operate the ATA independently of a stun server. The benefit is that phone service can continue no matter if the stun server is working. To do that see steps 1 to 4 below.

1. Forward the SIP ports and the RTP port range from the router to the ATA.
2. Set "STUN Enable:" no
3. Set "NAT Keep Alive Enable:" no
4. The ATA must learn it's public IP address, either through normal SIP registration, or place your public IP address in the 'EXT IP:' field).

I understand that you have not configured port forwarding in the routers, and that's OK. My question now is; are any of those SPA3102 units able to receive a call within the first 60 seconds after SIP registration to the Voxalot proxy?

That is what I noticed:
If I call from a different Voxalot account, it reaches the device after at least 15 seconds (whereas it used to be instant until last Saturday). But instead of getting to the VOIP-to-PSTN Gateway as it has always done, it keeps ringing until the voicemail picks up.

Two of those SPA 3102 that are registered with two different accounts, with different IP, started behaving weirdly on the same day without my intervention.

Problem solved.

It turned out that stun.xten.com no longer works properly.

I replaced it with stun.voxalot.com:3478 and that fixed the issue.

Thanks everybody for helping.

Funny, I thought I suggested something to that effect but you dismissed it from consideration. :p Take note people, weird global effects of suddenly not being able to call out or receive calls are most frequently related to NAT traversal problems, which for most of us are quite closely tied up with the STUN server we are using, rather than 'problems' with the providers itself.

No, I did not intend to dismiss anything.
Simply, I saw no reason in changing something that used to work without a single problem for more than an year.
Therefore, I decided to keep on testing until I find out why both devices stopped working at the same moment.
I still do not understand why stun.xten.com does work with the Voip provider registered under PSTN line but refuses to do so with the provider registered under Line 1. The call simply does not go through and is not forwarded to Voip-to-PSTN gateway as it has always been.

So, the questions are still there. But since the other STUN does the job I will put them on hold until somebody more knowledgeable than I am gives me a clear answer.

I can not believe I am the only one who used stun.xten.com and faced this problem.

Initially I was was puzzled that your ATA could not be contacted just because a STUN server failed. Then I thought maybe you don't have "Handle VIA received" and "Handle VIA rport" set yes. When STUN is not available there is another way the ATA can learn it's public IP address and public SIP port number. It uses "Handle VIA received" and "Handle VIA rport".

Apparently you have "Handle VIA received" and/or "Handle VIA rport" set no, so without STUN your ATA didn't know some important details, part of the SIP address at which Voxalot tries to contact your ATA to connect calls. Without the public IP address and public SIP port number your ATA registered using it's LAN IP address and LAN SIP port. Voxalot then tried to connect incoming calls to a wrong SIP address, for example; 123456@192.168.1.101:5060, note the LAN address and non-NATed SIP port number, which of course did not reach your ATA. After some time (Ring duration at your Voxalot account) Voxalot connected the call to your voice mail.

Below are some important settings for Linksys ATAs behind one or more NAT routers, when not using port forwarding in the router(s). If you may be behind symmetric NAT I recommend setting "Symmetric NAT Handling" to 'Yes' in your Voxalot account.

(under SIP tab)
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: no (or yes to automatically detect if you are behind symmetric NAT)
STUN_Server: stun.voxalot.com:3478 (or any STUN server such as 'stun01.sipphone.com:3478' or 'stun.sipgate.net:10000')
NAT_Keep_Alive_Intvl: 179 (sometimes 119 or 59, use highest number that works)

(under Line_1 and Line_2 (or PSTN_Line) tabs)
NAT_Mapping_Enable: yes
NAT_Keep_Alive_Enable: yes
NAT_Keep_Alive_Msg: 0000
NAT_Keep_Alive_Dest: $PROXY
Register Expires: 3600

----------

Optional settings, steps 1 - 4:
Sometimes its preferable to operate the ATA independently of a STUN server. The benefit is that phone service can continue no matter if the STUN server is working. See steps 1 to 4 below.

1. Forward the SIP ports and the RTP port range from the router to the ATA.
2. Set "STUN Enable:" no
3. Set "NAT Keep Alive Enable:" no
4. The ATA must learn it's public IP address, either through normal SIP registration, or place your public IP address in the 'EXT IP:' field).

I had simply followed the instructions shown under Voxalot FAQ for setting up SPA3102, the only exception being the NAT_Keep_Alive_Intvl:15
Since the devices kept working properly, I never bothered changing whatsoever to their settings.

They used to be and still are behind their own built in NAT routers. Never had any problem, so there was no need to do any SIP port forwarding.

Thanks for your advices, I might need them in the future.

i have also an spa3102, but i do not use STUN server or enable NAT, when r they necessary? what r they for (in few words)

If your ATA is behind a NAT router and you want to have low voice latency by using the shortest path for voice packets to/from the remote party, then you must use your public IP address and public RTP port number as the RTP Connection Address inside SIP/SDP packets. If such details are not used then the voice packets will be routed through Voxalot, not directly between you and the remote party. In order for your ATA to know it's public IP address and public SIP and RTP port numbers you need to use STUN, or forward the ports so that the public port numbers are the same as the LAN port numbers. In order for the ATA to actually use the details learned through STUN or other method, you must use "NAT Mapping Enable" as well as a few other settings.

i think i am not behind a NAT router, the ATA is just connected to my modem at home and same for the remote ATA, so i think i do not need all that ?

If the ATA is has a public IP address then of course NAT traversal methods are not useful.

don't know about public IP, i am just a simple user having internet from my ISP, at home i have only the modem they provided to me connected to the spa3102 then to my PC