SIP Peer Unreachable

Alright, here’s the scenario i’m running into. Let me know what outputs you’d like to see.

I have a * box that’s on the public net.
I have 40+ Aastra 480i phones inside an office LAN going through a NAT.

Everything works perfectly 90% of the time. Where I run into problems is occassionally dialing a specific extension returns the “busy” voicemail even when the line is not in use.

sip show peers shows the status of that extension to be UNREACHABLE.

As long as the phones don’t show as UNREACHABLE everything works perfectly.

Here’s what I’ve tried so far. I’ve tried completely disabling the qualify statement, that just makes it next to impossible to reach the phones altogether. I’ve tried changing the length of the qualify period, currently it’s set to 6000.

Any ideas?

One bug with AAstra phones you should be aware of-

In the AAstra phone setup (config files or web ui), there are two NAT options. There is SIP NAT IP (or something like that, feed it your external IP, this works correctly) and SIP NAT PORT. SIP NAT PORT does not change the local SIP port of the phone as it should, rather only changes the contact header of the phone to refer to a different port (and packets are still sent from and must be recieved to port 5060). I have contacted AAstra about this, the support guy I talked to agrees it’s a bug but the engineering department disagrees, its not a bug its a feature :smile:

The problem comes when NAT mappings kick in. You have pre-nat connections from the phones:
phone1:5060 - asterisk:5060
phone2:5060 - asterisk:5060
phone3:5060 - asterisk:5060
and nat turns that into
wanIP:5060 - asterisk:5060
wanIP:5060 - asterisk:5060
wanIP:5060 - asterisk:5060
obviously removing the differentiation. Thus when asterisk sends ANY packet back, it will go to whichever phone recently transmitted, which probably won’t be the phone it was meant for.

The phones should be on different local ports, which is what SIP NAT IP should do. This would create:
phone1:5060 - asterisk:5060
phone2:5061 - asterisk:5060
phone3:5062 - asterisk:5060
and nat turns that into
wanIP:5060 - asterisk:5060
wanIP:5061 - asterisk:5060
wanIP:5062 - asterisk:5060
which are obviously different and will not be caused trouble by nat mappings.

so if you are putting multiple AAstra phones behind a NAT registering to a remote * server, it will probably not work reliably until they fix this. I would suggest emailing aastra about it, tell them you consider it a bug, the support guy said the more people report this as a bug the more likely they are to get ti fixed sooner…

I’m actually avoiding the Aastra NAT settings and allowing the NAT itself to handle that with them.

The latest Aastra Firmware combined with a well built NAT seems to do a world of good in keeping the ports unique, right now an example of 4 clients as per sip show peers:

Name/username Host Dyn Nat ACL Port Status 253/253 xxx.xxx.xxx.xxx D N 65083 OK (56 ms) 242/242 xxx.xxx.xxx.xxx D N 60471 OK (53 ms) 236/236 xxx.xxx.xxx.xxx D N 61625 OK (114 ms) 234/234 xxx.xxx.xxx.xxx D N 58203 OK (57 ms)

So as you can see, the ports are definately unique, and both the phones, and the server is aware of that.

interesting. the issue i spoke of was present in 1.4.1 but i have not tried 1.4.1.2000 (the new one that just came out)… that looks encouraging.

OT.[quote=“IronHelix”]SIP NAT PORT does not change the local SIP port of the phone as it should, rather only changes the contact header of the phone to refer to a different port (and packets are still sent from and must be recieved to port 5060). I have contacted AAstra about this, the support guy I talked to agrees it’s a bug but the engineering department disagrees, its not a bug its a feature :smile:[/quote]

I happen to agree with the engineering :smile: Consider this use case:

phone1 (IP1:5060) --\ /----- (5060) -----\ +------+ router (public IP) +---- phone1 (IP2:5060) --/ \----- (5061) -----/

Suppose the NAT router forwards external 5060 to IP1:5060, and external 5061 to IP2:5060. For an external contact, a message to sip:PublicIP:5060 will be routed to phone1’s port 5060, one to sip:PublicIP:5061 will be routed to phone2’s port 5060. This would be expected behaviour. There is no bug in this. Right?

What really is buggy is that many home broadband routers today is crippled in port forwarding. Unlike many older home routers, the Linksys and a Belkin I use only allow port forwarding from the same port number. (And what’s the purpose of port forwarding again?)

to cope with these buggy NAT routers, what could have helped is for the phone to have yet another parameter to specify local port. That would be another feature, not a bug fix.

well I think we are talking about two sets of bugginess.

You are correct that if you forward external ports other than 5060 to phone ports 5060, then assuming the proxy honors the contact header this should work.

You are also right that many home routers don’t have good port forwarding, only forward to the same number. It isn’t as flexible but it is useful, ie make a web server work, forward * ports, etc. It just doesn’t rewrite the port number when rewriting the NAT.

So now assume you have a dumb router, and it only has one to one port forwarding, no port rewriting. In that case AAstra phones become near-unusable, as you can set the SIP NAT PORT to be port 5061 but the phone won’t listen on 5061 and packets won’t come from 5061.

The result is that for it to work as it is currently, you need to 1. have a router that supports port number rewrite forwarding, 2. configure the router to do so, 3. set that phone to use that forwarded port, and 4. hope your sip proxy is smart enough to recognize the contact header instead of just returning the packet from whence it came.

Now OTOH lets assume SIP NAT PORT does what i think it should- make the phone listen on that port, send packets from it, etc generally use it as the local sip port. This makes things far easier.

  1. dumb routers do not even need configuration (at all), as each phone will make its own nat mapping with a unique external port. use qualify= to keep the mapping alive and you are done- no user configuration of router required.
  2. even if the proxy is dumb and just returns the packet, thats fine
  3. the only lost functionality is dial by IP- you can no longer dial the phone by IP because it won’t be listening on 5060 anymore.

So I guess you could argue that it’s not so much a bug as missing functionality, as both use cases would work. However IMHO, one setup makes far more sense than the other…

:smile: I’m gonna try and drag this back to my problem.

The router is not a dumb router, but a configured and stable bsd box that is doing port number rewrites.

Does anyone have any idea how to correct the intermittant “unreachable” status?

ah sorry try this
for each phone define SIP NAT IP as the external IP of your network
define SIP NAT PORT as a unique port number for each phone. Forward that port to port 5060 on each phone.
set qualify=yes

or maybe upgrading them all to the latest 1.4.1.2000 firmware will solve the problem by itself…

As posted earlier, they’re all getting unique ports on their own, they are all running 1.4.1.2000 as of yesterday. Qualify has been set from no to yes, to varying numerical values.