Problem with receiving incoming calls on Andrews & Arnold VoIP

[#1]

As @MisterW said, try with it on and if that doesn't work, turn it off.

STUN is a just a protocol which in this case is used to tell the calling client what its external IP is, so that during registration, the remote server can be told where to address incoming SIP & RTP traffic. I have not found it to be necessary with A&A, but it very much depends on how nicely your VOIP server and A&A play together, how your server traverses the NAT Gateway and other helpful 'magic' that may or may not work.

A&A have a good explanation on their support site on how VOIP works and how NAT can be a pest due to the bi-directional nature of making outgoing and receiving incoming calls.

[#2]

Thank you so much for the explanation, I really do appreciate the help and support you guys are providing.

I've made the changes suggested and will report back on how things are going.

[#3 · Accepted solution]

@bromleyboy21 Do I want to try turning on NAT mapping or not?

I've not come across that option on a voip device before but having read that thread that @rflitcroft linked, I'd suggest leaving it disabled for now, but set NAT keep alive enabled. If incoming calls still don't work then try with NAT mapping enabled as well.

To try and explain:-

The local IP address of the ATA frequently appears in the payload of a SIP message. The NAT device on this network is going to replace the local source IP address with a publicly routable source address, but only for the IP header on this packet. When the provider’s VoIP equipment sees this packet, it can not reply to this local address.

Now most voip providers systems are NAT aware, and so ignore the address in the SIP payload and instead use the source address in the IP header, so normally no other action is needed by the ATA.

It would seem that the NAT mapping option on the Cisco ATA is trying to handle this by replacing the address in the SIP payload with the public IP. This is similar to what the SIP Alg on the router would do.

In my experience neither of these options are normally required, all that is necessary is to keep the router NAT mapping open by ensuring that keep alive packets are sent. 

STUN is a method by which the ATA can determine the actual public IP of the connection.

[#4]

To give an update: yesterday I left NAT mapping disabled and enabled NAT keep alive.

Since then there have been 7 incoming calls and all have worked perfectly and come through the Cisco box to the home phone!

I'll keep an eye on things for the next couple of days but it looks like the problem may be solved!

Many thanks for everyone's help and support with this, my in-laws are very happy.