BUG 6757i

[womble1]

Hi,
in the past i have used 6757i's a lot, great phones, always do what I want apart from NAT issues about 4 years ago.
However I upgraded one server to asterisk 11 with the latest Freepbx.... now I have a problem and it's confirmed right across the board for this server.
Since only the server software has changed and nothing else it must be the server.
Every other remote phone is fine, Bria soft phone on iPhones works without error, remote handheld Gigasets are fine.....
All remote Aastra's have issues, single phones at a remote site register but have one way audio issues more than one handset and they all eventually deregister or can't register....
if phones are onsite with server of course no issue at all.
I am sure the aastr's Nat issues have returned and are having a punch up with the new server.
I am now considering just dumping all the remote 6757i's and replacing with a good ( not too expensive desk phone) it needs to have simlare features etc ...
The router on the server is a Draytec 2830 have swapped for a 2850 and back again as it wasn't that....
my questions therefore are.
1/ has anyone seen this ?
2/ is there a solution
3/ since it's only 6757i's that are having this issue a good replacement is now required... any suggestions.

 

[Hyksos]

if you change them, I'll buy them for cheap and they'll work the minute I plug them in

Doesn't make alot of sense, the phone should not even be aware that it's NATed, if it is, that might be your problem.
Once the phone is configured without any NAT specific configurations, which is what should be done, the rest is out of the Phone's control and unrelated to it.
It's in the remote site NAT device, your server's NAT device and your PBX configs.
The PBX should be aware that this phone is NATed though... and once rightly configured these phones can work. Probably thousands of them right now doing NATed calls, as we speak, all over the world.

You're just facing the most common VOIP problem in the entire history of VOIP and concluding you have to switch the phones... Seem weird.

When a phone's NAT support is a factor in a problem, you're doing things wrong by having the phone aware that it's NATed. Once that is out of the question, blaming the phone stop making sense.

Feel free to disagree, of course.

 

[womble1]

no you are wrong.
just installed a Yealink 28T and the issue goes away... Aastra have always had NAT issues.... but there are other good phones out there.... all other phones are OK...
I would only se Aastra for onsite stuff which I do... exclusively.... off site Yealink....

 

[mag]

I experienced similar issues with Aastra's and NAT on a new install after running perfectly on an older system for a long time. Check your extension settings and make sure that NAT=yes on each remote extension. This of course assumes you have the other SIP nat settings correct...

 

[womble1]

Just bought a nice yealink phone... no issues...

 

[hbonath]

How is asterisk configured?
Does your PBX have a public IP or behind NAT?
Does your Asterisk SIP Settings have NAT=yes?
What firmware are you running 3.2.2.x?
When trying to register, what does the Web GUI state as the registration status?
Do you have any packet captures?

I'm not familiar at all with Draytec routers, is this a firewall trying to do some sort of SIP ALG?

When troubleshooting this type of thing, I typically will try to packet capture both ends, PBX side, and remote phone side. Then using Wireshark, will line up the packets to make sure they are traversing properly through any firewalls, and also inspect the SIP messaging to ensure that it's not being altered by a device in between.
With Asterisk nat=yes it should use the Public IP Address in the source Layer 3 header as the source IP, with the Layer 4 UDP Port as the destination port for the phone in stateful communications and essentially ignore any of the Layer 7 SIP from info which likely has the internal private IP.
In my experience you actually *want* to see internal IP's in the application layer, as it shows that the IP information isn't being mucked with.
NAT=yes in the endpoint config should tell asterisk to ignore this.

Asterisk 11 also supports ICE and STUN (I think!) so there may be a chance that if there are STUN settings in the phone you may want to remove them.

 

[hbonath]

On a side-note just looking into the Draytec device, it looks like the one you are using has some sort of PBX built-in?
http://www.draytek.us/index.php?opt...9:vigorippbx-2820&Itemid=664&lang=us#features

There's probably a *good chance* that it may be trying to "help" you out by changing the SIP packets as it egresses the device and then when the off-site PBX receives the packets it's not effectively sending the return acknowledgements, a packet capture could confirm this if you have a capture point on the phone itself, on the public interface of the remote site firewall, and then then on the PBX itself and comparing the same packet in all 3 capture files to see what's going on.