ATL Telecom IP300S - Manual (Page 97)

IP SIP Phone v2 User’s Guide Mar. 2005
[97/100]
c. Proxy Server
d. Registrar
Configure SIP domain applied from service provider as appropriate. To apply for a public
domain account, you may go to
www.freeworlddialup.com or www.iptel.org .
3. Check for NAT and Firewall settings:
『 』 『 』 Go to Network / NAT & firewall , enter the STUN server IP provided by your
service provider. For example, you may enter “stun.qt.com” or “qt.com” or “larry.gloo.net”
for test purpose.
Please refer to chapter 6 – 『
』 NAT Traversal to determine the best way to traverse your
network address translator or firewall deployed by your ISP or company.
4. Experience long-delay or poor response time on making calls (roughly 10 seconds):
The most possible cause is that you have enabled STUN to traverse NAT, but the STUN server
is either down or unreachable.
『 』 『 』 『 To verify the exact reason, please go to Network / NAT & firewall and click Set
』 『 』 and Diagnose NAT to figure it out. If the result is Firewall blocks UDP and you are
pretty sure that you are not under such a network condition, you should check for the DNS and
STUN server, making sure they works normally by Pinging for their viability. Otherwise, you
『 should pick Static NAT IP/UDP 』 Map as the way to traverse NAT.
5. After setting up a call, it always disconnects automatically after 32 seconds.
This may be due to the fact that either the involved SIP proxy servers and / or the terminals
(either the caller or callee) are behind NAT, such that the ACK signal cannot be transmitted
through the signaling path.
If only the terminals are behind the NAT, please refer to previous parts for NAT & firewall
traversal. On the contrary, if it is the SIP proxy that behind NAT , which has a private
unroutable IP address, then it hardly leaves room to solve this problem except for direct IP
dialing (because most proxy servers demands record-route, but it fails if any of the involved
servers bear private IP).
6. Experience one-way voice (or no voice could be heard by either party) after call setup.
This is because one of the terminals resides behind NAT and it does not specify a way to
traverse it reliably. Normally, the one who cannot hear voice mainly because it specifies a
private IP address to receive voice media on call setup phase; as a result, the peer starts to send
voice media to this unroutable private IP address and the voice packets will get lost since
private IP are not routable. To verify the real cause:
i. If both parties have connected and engage in calls already, please 『 go to Call
』 『 』 Statistics / Channel Info page to view the following information and check