ATA becomes disconnected

I have an Grandstream 386 ATA connected as an extension,
however it tends to disconnect from the Asterisk and stop
receiving/making calls. I have still yet to determine
how often it does.

The fact is that when I reboot the ATA, everything is fine
again.

The IPTel's status panel of Asterisk shows that my extensions
are logged in, but the fact is that it cannot receive calls.

Any idea of this issue?

Thanks in advance
Alejandro

RE: ATA becomes disconnected

Do you observe this with any SIP service or just the PBX?

Best regards,
Pascal

Well, with inphonex.com I don´t have this problem.
My setup with them is of 2 accounts under the same NAT router. One account is in a softphone and the other in my ATA.

BTW when I put one I-P-TEL extension account in my softphone it works fine and the connection never drops.

Can I ask how many and what trunks you have in your config? I just came to post a bug that I have now confirmed. Please see my post from the same date as this post in the BUGS section

There is a feature called KEEP ALIVE, that supposes to do a kind of "ping" to the Asterisk server.

For some reason I don´t know this doesn´t work when I use I-P-TEL SIP server (it works with inphonex).
It seems, that due to this, the ATA become unregistered.

If you are referring to a NAT keep alive, this would imply that your problem is NAT related. Have you tried opening Ports on your router? Also I hope you are not using the same SIP Port for both User agents. If the NAT Keep alive interval is set too high, the NAT keep alive will not always work. try lowering the NAT keep alive interval.

I do not believe that all SIP servers support NAT keep alive however.


If you do not open ports, try using a STUN server SUch as one from FWD or from SIPPhone. It does not matter which STUN server you use.


Each UA on your LAN shopuld use a different SIP Port. In the case of a Grandstream, I believe it has an option called USE RANDOM PORT . This exists for exactly that reason!

As for Xlite or Xpro, try selecting a SIP port OTHER than 5060

I wonder if STUN would affect the voice quality..

No, STUN has nothing to do with voice quality. It's only purpose is to identify the external IP address/port being used if your ATA or softphone is behind a NAT firewall.

Voice quality is determined by selection of CODEC and by bandwith/congestion on the network connection between your ATA/softphone and the other party's ATA/softphone. See discussion elsewhere about audio bypass for one possible way to improve voice quality (by bypassing i-p-tel's servers).

This is message is to confirm that everything is fine and the connection is not dropped anymore.

Yes, I had to use STUN finally.

This post has been edited 1 time(s), it was last edited by vir on 24.03.2006 at 22:27.

I had this problem as well on a Sipura. I had to manually put in the DNS address that I was using and it was fine. Yesterday, my Sipura could not hold a connection more than 5 minutes. Today it is 18 hours and still holding.

lost reg on SOME accounts

I started setting up an account for a friend, and changed the programming on my SPA 1001 to my friends account to test it. One thing I noticed weeks ago is that to change a UA from one account to another on this server, sometimes it is necessary to change the SIP port. I did that as well as the account. I started experincing ther lost registration described here. UA will register however 15 minutes later it is not registered. If I wait sometimes it re registers, then not again. I have tyried lowering the SIP Reg Interval and still no luck.

The registration seems flaky ONLY ON THE NEW ACCOUNT! The old one (mine) works fine!

Also, I attempted to connect a Mediatrix 1104 to this server and was never able to register! I tested the Mediatrix with other servers and it registered fine. None of them however were Asterisk based servers.

This post has been edited 1 time(s), it was last edited by sup on 29.03.2006 at 23:42.

RE: ATA becomes disconnected

Thank you for reporting this behaviour. We extended the PBX to support KEEP ALIVE now.

Best regards,
Pascal

RE: ATA becomes disconnected

What is the right value of registration timeout for PBXes?

SIP re-registration values

There is no right or wrong value really. It depends on the type of SIP User Agent and whether it is behind a NAted firewall or on a public IP.

The values I use range from 180 sec to 1800 sec, on a variety of SIP User Agents.

RE: ATA becomes disconnected

ATAs sitting behind NAT with dynamic IP connection often experience disconnections from SIP proxy specifically when ISP changes IP address.
Lately it started to bother me for real, so I went with some extensive googling - I found it’s quiet a common problem.

When ISP changes “external” IP, connection interrupts for a minute, and then router restores it under new IP. ATA, however, cannot re-register, getting “Can't connect to login server” (for Linksys devices) message.

Rebooting ATA doesn’t help, but rebooting router fixes the problem. I suspect rebooting router simply flashes NAT tables, and this allows ATA to re-connect. Which leads me further: ATA can contact SIP proxy (pbxes.org), but SIP proxy responds to the old IP, so ATA doesn’t get response and concludes it can’t contact the server. Somehow flashing NAT on router makes ATA to refresh it’s IP:port on either SIP proxy, or STUN, or both, so SIP proxy can pass authentication confirmation back to ATA. Note - I'm talking about authentication stage, far prior to sending SIP INVITE from proxy to ATA.

Does it make sense? Many providers have “Behind NAT?” checkbox, which I suspect supposed to take care of this.

Any ideas how can this be handled without rebooting router?

RE: ATA becomes disconnected

Your post in this thread brings up a few sticking points, for which there are no exact answers, only guidelines.

The SIP as well as the H.323 protocols were designed with public IP addressing in mind. NAT and PAT were invented later to deal with the IPv4 addressing space depletion, since no entity wished to move on to IPv6.

As a result SIP User Agents, which are not located on the same subnet with their associated SIP Proxy, will not work flawlessly all the time. NAT & PAT traversal methods were invented to mitigate the issue, but do not work in all cases (i.e. Symmetric NAT).

So the question in everyone's mind is, what can we do for VoIP in this state of affairs. The answer depends heavily on the answer to this question: How important is your VoIP implementation for you?

If the answer to the above question is "Very Important", then you need to get as many SIP UAs as you can away from NAT and PAT routers, and assign to them Public IPs. Quality hosted VoIP implementations depend on the absence of NAT and PAT between the SIP UAs and their SIP Proxy.

Depending on your setup you should inquire with your provider to supply you with a range of Public IPs. Please note that we are talking about Public IPs, not necessarily Static Public IPs. Dynamic Public IPs will do fine too, since the SIP User Agents will know immediately about the IP change and attempt to re-register as soon as possible.

But you might think: "my provider will want to charge me a lot for Public IPs, or they don't know the difference between a Static Public IP and a Dynamic Public IP, etc". In that case you have a single Dynamic Public IP and you should make the most of it. Buy a router with built-in FXS ports (Draytek 2700VG), or an ATA with a built-in router (Linksys SPA-2102), or a DECT phone with a built-in router (Siemens xxx IP).

The public interface of these routers communicates very well with the ATA part, and will let it know immediately about an IP change (so it can re-register immediately), allow it to properly work with SIP Re-Invites (so the RTP packets will travel directly between the the ATA and the SIP Proxy of the trunk provider or the other ATA on extension to extension calls), prioritize the RTP packets so they can be handed off to the broadband connection faster than the rest of the packets (browser requests, P2P downloads, etc) as well as other more subtle functions.

But what about the rest of my ATAs. IP-phones, soft-phones, which will remain behind the NAT and PAT routers? Well they will have to suffer from the intricacies of NAT Traversal, without Public IPs. But, if you set your DIDs with Inbound Routes on Ring Groups, then every phone call will ring on the phones attached to the router, even if all other ATAs and IP-phones have not had a chance to re-register yet.

In closing, the advent of VoIP saves us a substantial amount of money. But reliable VoIP implementations require a little bit more investment, if we want to depend on VoIP for PSTN-like availability.

RE: ATA becomes disconnected

Diafora, thanks for the detailed reply, and it's totally clear that using NAT introduces some complications. I however never seen office phone network where every extension had its own public IP.

The problem I asked about is somewhat different. After public IP change occurred, old registration expired, and ATA was trying to re-register with no success, for hours, always displaying error “Can't connect to login server” - until router has been rebooted. In my last post I tried to think about possible reason of this phenomenon.

As I said, I believe this is a common glitch related to either NAT or SIP proxy NAT handling (Session Border Controllers?), and I just hope someone with more networking experience might shed some light on this NAT behavior and possible workaround.

This post has been edited 1 time(s), it was last edited by dor on 19.08.2008 at 04:10.

RE: ATA becomes disconnected

The reason you have never seen office phones with Public IPs, is precisely the location of their PBX in the office LAN which most of the time has two ethernet interfaces (Public & Private). But what we have here, is a hosted PBX (on a Public IP) with SIP User Agents behind NAT routers (on Private IPs), thus with all the issues associated with NAT Traversal.

As I mentioned in the beginning of my post, there are no exact answers, only guidelines. As you have discovered, VoIP behind NAT is somewhat problematic, but since most of the VoIP providers require the use of their own routers/ATAs from their end users, custom implementations such as in our case, are facing issues due to NAT.

The current state of NAT Traversal has reached its' limits, and the introduction of IPv6 will render it obsolete, but until then its' limitations will be with us. Regarding these, I have provided at least two alternatives, to make our VoIP life a bit easier in the meantime.

If you wish to run a call center behind a single Public IP, you can, but with the limitations I have mentioned. Unfortunately there is no magic bullet!