Remote IP Phone Quick Start Guide


Setting up remote IP phones is fairly straightforward, but not all of the configuration is intuitive. This document should be sufficient to get remote IP phones working via NAT for most customers, but if your client has a complex or non-standard configuration, or you would like a more detailed explanation of these settings, please see Chapter 25, Enterprise VoIP Network Management in the Administrator manual. This guide applies MaxCS versions 6.5 and above.

Enabling SIP NAT Support:

SIP NAT support is what allows remote phones to communicate with AltiGen without the need to open ports on the firewall/router in front of the remote phone. If this is not enabled or not configured properly, phones will often register but have no talk path.

1) Launch Enterprise from the VoIP -> Enterprise Network Manager dropdown in MaxAdmin.

2) On the IP Networks tab, and on the right hand side press add. Input the client's IP range for their local LAN. Set the Pipe to Local, and check Private Network. You will likely receive a message that the server's IP is within the configured range, you can click OK and ignore this message.
        a) If you have remote users on VPN or a remote office on MPLS, these sites will likely not need to use NAT Support either and should have their IP ranges added as local and private as well.
        b) In most cases you will not use the Public and Intranet pipes, even if you have sites that would be defined as Intranet. See the Administrator manual for more details.

3) Check the Enable SIP NAT Support checkbox.

4) Enter the public IP address of the server. This should be the same IP that your remote phones use for their AW server. If you aren't sure, check with the client's IT administrator or go to
        a) DO NOT check the 'enable virtual IP addresses support" checkbox.

Port Forwarding:

While SIP NAT Support will typically allow remote phones to function without any firewall configuration at the remote side, we do require certain ports be opened on the AltiGen server side. The full list of ports AltiGen uses can be found in Appendix C of the Administrator manual. The information here is the minimum needed for AltiGen IP phones to function behind NAT. Please note that AltiGen will not be able to assist with the configuration of your Firewall or other network equipment.

1) Forward the following individual ports to MaxCS: TCP ports 10032, 10064 and 5061. UDP port 10060.
        a) Optional: UDP port 69 for TFTP firmware updates.

2) Find out the port range for your Voice Resources. The easiest way to do this is to go to View -> Current Resource Statistics in MaxAdministrator. The Local Ports column lists all of the UDP ports used by the system. Forward these ports to MaxCS.
        a) To find the port range manually, take twice the number of VoIP resources in the system and add that to the base port (49152 for XP, 2000, 2003 or 49664 for 2008). For example: If you have an Office 1G running XP Pro with one 12 port and one 30 port board, your UDP port range for RTP (talkpath) traffic would be 49152 through 49236 (42 VoIP resources total, times two ports per resource is 84, added to the base port of 49152 gives you 49236).


Our default configuration will use G.711 local/Private IP's and G.723 for remote. This is usually fine since the majority of servers will come with both G.711 and combo codec resources. However, if the system is an Office Chassis with only a single 30 port IP board, the system will not be able to connect G.723 or 729 calls since it only has G.711 resources.

If you find yourself working on a system that has only a single 30 port IP board, the easiest way to ensure you will not have codec problems is to simple change the Codec Profile for the default codec to G.711 only (this is done from the Codec button at the top menu of Enterprise Manager). Be careful if the system is part of an Enterprise Domain since the Codec Profile is for the entire domain. You can also control what codec phones will use by defining an IP or range of IP's in the IP Codec tab, under Servers in Enterprise Manager.

Testing and Troubleshooting:

Once you have configured Port Forwarding, the Enterprise Manager IP Network tab, and confirmed your codec configuration, you are ready to login a remote phone. Here are some common symptoms and their usual causes:

Issue: Phone registers but does not get any talkpath and cannot see the phone go offhook in MaxAdmin.
Cause: Typically caused by incorrect NAT Support configuration. Verify the public IP is entered correctly and Enable SIP NAT Support is checked in the IP Networks tab of Enterprise Manager. If the Enterprise configuration is okay, then it could be that the client's Firewall/Router is also providing SIP NAT Support. We want the AltiGen server to handle SIP NAT, so this should be disabled on the customer's equipment. It could be called SIP NAT, SIP ALG, SIP packet inspection, SIP packet fixup among other things.

Issue: Remote IP Phones register and have talkpath, but local IP Phones get no talkpath.
Cause: This is also SIP NAT Support related, but this issue is caused when NAT Support is enabled and the Local IP ranges haven't been defined as Local and Private in the IP Networks tab of Enterprise Manager.

Issue: Remote phones register, can place and receive calls but only the remote phone side of the call has audio.
Cause: UDP ports for RTP traffic may not be open. If the issue is intermittent, they may have some or most, but not all of the ports open.

Issue: Remote phone appears to register but then goes to SIP Reg Fail status.
Cause: Our phone is not receiving a response from the server from it's SIP Invite. Check that port 5061 is forwarded to the MaxCS system.

Issue: Remote phone registers, can place/receive calls but the call disconnects as soon as it is answered.
Cause: This is typically caused by a resource availability issue - such as a phone attempting to use G.723 on a system that has only G.711 resources. Review the Enterprise Codec configuration and verify they have resources for the codec that the remote phone is attempting to use.

Issue: Delay, static, drop out, garbling and other quality issues.
Cause: These types of call quality problems are almost always related to network issues - packet loss, excessive latency and jitter can all impact call quality greatly. Detailed troubleshooting of VoIP quality issues is beyond the scope of this document, please see our article on the Network Log Viewer (IPSViewer) or contact TSO if you are unsure on how to proceed with troubleshooting a VoIP quality issue.


No attachments were found.

Related Articles

Visitor Comments

Article Details

Last Updated
16th of April, 2012


Would you like to...

Print this page  Print this page

Email this page  Email this page

Post a comment  Post a comment

 Subscribe me

Subscribe me  Add to favorites

Remove Highlighting Remove Highlighting

Edit this Article

Quick Edit

Export to PDF

User Opinions

How would you rate this answer?

Thank you for rating this answer.