BYOD Users: Testing Michigan Datacenter

[racerdude]

Would you guess then that those of us who have major port forwarding enabled for many years now, can disable the port forwarding?.

I used to have dozens of port forwarding rules setup on my router for each of the RTP audio providers, it was a real pain especially when I found a new one (one way audio) and had to go add the port forward rule and redial or have them call me back. I finally just gave up and port forwarded all UDP traffic on my RTP ports to my SPA2102 and haven't had any issues since. I did change the RTP port range from the standard ones to a different range and also the SIP port numbers on my SPA2102 just to avoid any issues with random calls from hackers that I've read about on other message boards.

But to answer your question - if you do require port forwarding on the RTP ports you can try just setting it to the ones I posted above for outgoing calls and for incoming calls I am seeing 174.36.46.53 (verify that these are the same ones for you). This should work until they change to proxies and you get one way audio..... Or just forward everything like I ended up doing and if you get strange calls then change the RTP ports to a different range.

[burris]

Thanks for your reply..

Many years ago Brandon advised me to port fwd 5004-65000-Since then I have never had a problem.
I think this is safer than DMZ and it doesn't affect any of my other devices or network.

Maybe Tim will offer an opinion at some point..

thanks again..

[racerdude]

It's actually not necessary to port forward that entire range to your ATA, it would work but is overkill. If you need port forwarding at all due to one way audio (not everyone needs to do this), normally you would just port forward the RTP port range defined on your ATA. On my SPA2102 the default range is 16384 to 16482, you would setup a UDP port forward rule to your local ATA IP. In my case I changed this range to something different that didn't conflict with any other programs I use (i.e, 17000 to 1709 and forwarded just that range. If you forward 5004-65000 then it could interfere with other programs that might also need port forwarding, for example Plex Server which uses port 32400.

It is slightly better than using the DMZ which would forward everything to your ATA, but if you want to limit which traffic goes to the ATA it is better to just use the RTP port range. In my case I didn't have to port forward the SIP ports, but if you do that would normally be 5060 (and 5061 if you have 2 lines).

Of course if everything is working fine and you don't get any random calls on your ATA then you could leave everything alone and not worry about it.

[burris]

Thanks again....

[chpalmer]

For my 502 I have (in my edge firewall) my firewall rules set to allow destination ports 5004-5059 from 174.36.46.0/25 any port to my 502 with no port forwarding. When I make or receive calls this is the network that the GS 502 connects to for RTP.

For my RT31P2, PAP2 and RTP300 same but destination ports 16382 - 16484.

These are for sip-central01.voipwelcome.com the non BYOD server.

For sip7 (byod server) I see the same SIP server IP connecting for RTP. So it seems that they only proxy audio for the BYOD servers just to clarify.

I also allow from 67.228.190.148 for RTP to 16382-16484 at the house here where I have 3 Linksys devices. I do not recall but this may have been for the PBX. Doing a test from the PBX phone get RTP traffic from the PBX sip server however...

[racerdude]

Is anyone else having issues with sip7 today? I'm unable to register to this server but can register successfully to sip and sip-central01.

[GreenLantern]

Yes, starting Saturday 01/03/2015, we've been having issues with several accounts that were using SIP7.

We switched them to the SIP address, problem solved. But this kind of stuff really erodes confidence in the voipo network.

[GreenLantern]

Still ongoing issues with sip7 today... 01/05/2015

Seems that inbound calls ring once then die, or customer answers and gets no audio.

[VOIPoBrandon]

Hello,

Please retest at this time and advise if any further issues persists, thank you.

[racerdude]

Just did a quick inbound and outbound test call on sip7 and it appears to be working now. What turned out to be the issue?