All calls being sent to Voicemail

[Grahame]

Hi ctyler,

OK Thanks for that, I'll play around with the settings.

I'm still interested in the RTP settings for each account in the ATA. i.e should the RTP range be a different for each account ?

Best regards

Grahame

[kurun]

Yes, both RTP and SIP should be different in each ATA account.
If every IP user agent (soft-phone, IP Phone, or ATA) is forced to use different listening SIP Ports (Eg. 5060, 5062, 5064, etc) and separate RTP ports (Eg. 5004. 5006, 5008, etc), the overall SIP setup will be more stable.

What I find most stable when multiple devices are being used:
1) Fix the private IP address of each SIP device
2) Set up SIP ports, RTP ports as indicated above
3) Use a STUN server
4) Forward the respective SIP and RTP ports to the individual device fixed IP address

Of course to do this, you must have full access to your router and private network.

[ctylor]

I personally would avoid that Kurun, if I were you. It is an over-complicated setup that in fact is unnecessary.

You could have 10 SIP devices (ATAs, IP phones, and softphones) on your LAN at 10 different IP addresses, and each and every one of them could be using ports 5060 and 16384-86, and the router would sort it out just fine. All the devices (or computers) could get their local IP addresses assigned by DHCP to boot and it would still work itself out. That's the power of STUN and NAT routing. What happens is that to the outside WAN world 192.168.1.3:5060 would become something like 212.54.78.201:60445 and so even if you had a second device that was at 192.168.1.4:5060 it would be assigned something like 212.54.78.201:61225. In other words, there is more than enough port 5060 to go around when using a NAT/PAT router since all the ports get changed anyway to something else.

Network address translation - Wikipedia, the free encyclopedia
Port address translation - Wikipedia, the free encyclopedia

[Grahame]

Hi guys,

Thanks again for your replies. I think you are both right, it seems it's a question of two different strategies to address the same issue.

I also found this in another thread from Martin:
Quote:
So just to re-iterate, if you want to properly receive the ACK message from the other end point, and you are behind a firewall, you must either:

1. Use a protocol like STUN to perform client side NAT handling (Note: STUN is broken in SJPhone and needs to be disabled. Make sure the "Use discovered addresses in SIP" is unchecked. I suspect this is half your problem)
2. Open up your firewall ports and forward to your device
3. Register your device with a proxy that has built-in NAT handling capabilities. End Quote:

I'm using STUN, have the ATA in the DMZ and have Voxlalot doing the NAT handling, so I should have all bases covered ( unless I'm overcooking it ! )

I've got my other PC now working by bypassing the ATA and VoIP traffic stable by just using Voxlalot. I'm changing ISP and systems end June so I'm going to leave it there for the moment. I need the system running and can't give any more time to testing at the moment.

Thanks for all your help with this, I'll let you know what happens after my system change.

Best regards

Grahame






.

[ctylor]

Thanks Grahame. I am a firm believer in not touching your router's port-forwarding or DMZ settings when using VOIP, and letting STUN handle it all for you. The only occasion you should ever manipulate your router's port-forwarding settings are the rare cases when you are hosting a web or email server at your IP address and you need port 80 to get directed to the right machine. That means 99% of people don't need to manipulate those options in their router. These days, even bit-torrent or gnutella clients will manage port-forwarding for you (via UPnP), and with SIP and VOIP using correct STUN and NAT settings in your device will take care of it. Its also simpler with less to troubleshoot in case something goes wrong. My two cents.

[ozimarco]

Originally Posted by ctylor

I am a firm believer in not touching your router's port-forwarding or DMZ settings when using VOIP, and letting STUN handle it all for you.

I also came to that conclusion eventually. I used to have intermittent problems with incoming calls on my PAP2 until Martin advised me to disable port forwarding and enable STUN. This has been working flawlessly for many months.

[kurun]

Some clarification on my earlier post.
I always opt for the simpler solutions wherever I can, and I fully endorse CTylor's comments regarding letting STUN do the router sorting out.
My suggestion was primarily to address the problems I experienced when the same Voxalot account was logged onto by 2 or more ATAs/SIP phones operating behind the same public IP address.
For all I know, the problems may have been due to the particular router and SIP devices being used.

For a single ATA, I have generally found that using just DHCP & STUN is sufficient, without the need of any port forwarding.

For multiple devices logging onto different SIP services (Eg. Voxalot and FWD), STUN is also usually sufficient.

For whatever it is worth, Wikipedia states that "STUN will not work with Symmetric NAT".
Simple traversal of UDP over NATs - Wikipedia, the free encyclopedia

A word of caution regarding uPnP - Earlier this year, there were reports about a security flaw when using uPnP, and I have not found any indication that this is resolved.
Severe UPnP Flaw Allows Router Hijacking -- Computer Security -- InformationWeek
Flash UPnP Attack FAQ | GNUCITIZEN