Vitelity Inbound Calls go to voice mail
 

Voxalot does not stay registered correctly with Vitelity inbound for me. If I disable, then enable, the SIP register with sip6.vitelity.net, then it registers fine and I receive inbound calls. But a few hours later, inbound calls do not ring my ATAs and roll to Voxalot voice mail after the expected number of rings. Voxalot shows that I'm still registered with Vitelity.

Further, if I call using my Voxalot SIP number XXXXXX@us.voxalot.com, my ATAs do ring. (I have a Callcentric DID that forwards all calls to my XXXXXX@us.voxalot.com). That would imply that my ATAs are registered with us.voxalot.com (and the status of them tells me that they are).

If I then disable, then re-enable, the SIP register with sip6.vitelity.net, then my inbound Vitelity calls ring again for a few hours.

To summarize, it appears to me that something times out or gets out of sync between Voxalot and Vitelity, and the result is that inbound calls stop ringing by ATAs, and roll over go to Voicemail.

Any suggestions?

I've discovered that even when I directly call my Voxalot SIP number, the ATAs sometimes to ring. I tried about twenty calls, and several didn't go through. So I thought that perhaps the Vitelity calls would sometimes go through, so I tried many calls to my Vitelity number, but all of them didn't ring.

There are 2 legs here that you must address:

1. The leg between your ATA and Voxalot. To stabilse this leg you must address all your NAT issues. If you call one of the SIPBroker - PSTN Numbers and at the prompt dial *010xxxxxx and it "consistently" works, then the setup of this leg is complete.

If some of these test calls fail, then undoubtedly this is due to NAT keep alives. If this is the case, then check if your ATA has a NAT keep alive option and try using it.

2. Once the above is stable, then move onto the Voxalot <-> provider leg. As this is a front facing call you won't have NAT issues to contend with. The challenge here is whether the provider is compatible.

Anyway my advice is to try and break down the problem and isolate where things are going wrong.
.

I tried calling from one of the Voxalot local access numbers and never got a ring. But calling through Callcentric's direct forwarding continued to work intermitently. Then I reset the ATA, and everything worked fine for about 1.5 days, but then the same symptoms reappeared. Then I discovered something interesting.

I have two SPA-2102 ATAs that are not co-located. I am seeing the above symptoms with both lines of one of the ATAs, but no symptoms with the other ATA's two lines. This would tend to indicate that either the settings on the failing ATA are incorrect, or the ATA itself is bad.

Before I left the failing house, I printed out the failing ATA's Linksys information for all of the Voice tabs. When I discovered that the second ATAs was working fine, I compared its settings with those of the failing one. I thought I had set them up identically, but I was surprised to find I had not. The failing one had these settings (the working ATA's setting is in parentheses):

SIP tab:
Escape Display Name: yes
RTP Port Min: 16484 (vs. 16384)
RTP Port Max: 16582 (vs. 16482) - I changed the RTP port range to avoid conflicts between the two ATAs.
Substitute VIA Addr: no
Send Resp To Src Port: no
STUN Server: stun.callwithus.com (vs. stun.xten.com)
NAT Keep Alive Intvl: 15 (vs. 28)

Provisioning tab:
Resync On Reset: no
Resync Periodic: 14400 (vs. 86,400)
Resync Error Retry Delay: 900 (vs 14,400)
Forced Resync Delay: 14400 (vs 86,400)
Resync from SIP: no
Resync After Upgrade Attempt: no
Resync Fails on FNF: no
Firmware Upgrade Enable: yes

Regional:
No differences.

Line 1/2:
SIP Port: I set up each line to be unique across both devices
Ans Call Without Reg: no

I plan to go ahead and change the settings in the failing ATA to match those of the passing one, when I return to that location, and I'll update to let you know if that corrected the problem. I decided to post the above differences for the benefit of someone who might experience a similar problem. Would you expect any of those settings to cause problems in communicating with Voxalot?

NAT Keep Alive Intvl: 15 (vs. 28)

I seem to recall having a problem with setting this number too low on my Sipura, which was unexpected.

Substitute VIA Addr: no
Send Resp To Src Port: no

If these are no, then should we presume the four immediately above it are set to yes? I had heard that the 'standard' approach is either to make these two settings 'yes' and the other previous four 'no', or vice versa, the previous four to 'yes' and these two to 'no', but never do either all six to 'yes' or all six to 'no'. However that's going on someone else's understanding, this is not my speciality, so I don't really know for sure.

It does sound like you have 'bad' firewall/NAT settings from your above explanation so that is why I ask about these settings.

--Chris

Chris,

Thanks for responding! Regarding "If these are no, then should we presume the four immediately above it are set to yes?", the four immediately above it are set to NO. These are the settings for the failing ATA:

Handle VIA received: no
Handle VIA rport: no
Insert VIA received: no
Insert VIA rport: no
Substitute Via addr: no
Send Resp To Src Port: no

So all six are 'no'.