Inbound calls problem

[Juste]

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.

[ctylor]

Originally Posted by Juste

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. 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.

[Juste]

Originally Posted by ctylor

Funny, I thought I suggested something to that effect but you dismissed it from consideration. 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.

[boatman]

Originally Posted by Juste

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.

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).

[Juste]

Originally Posted by boatman

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".

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.

[mohnashaat]

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)

[boatman]

Originally Posted by mohnashaat

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.

[mohnashaat]

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 ?

[boatman]

Originally Posted by mohnashaat

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.

[mohnashaat]

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