Potential New SIP Providers - Thoughts?
-
@Minion-Queen
It should also be noted that they made it dead simple from a firewall standpoint. There's 1 ip for SIP and 1 ip for RTP traffic. That's it. Work through @TeleFox as he is partnered with Intelepeer and can assist you in getting a good deal. -
That's awesome! That will make things much easier.
-
@Minion-Queen said:
That's awesome! That will make things much easier.
They can do ip authentication (tie the trunk to a specific public ip) or the standard registration string (whichever you prefer).
-
Open the entire UDP range above 1024? like WTF kind of generic shit is that?
To me, that right there is a red flag. This provider cannot be serious if they cannot provide specific port information.
I believe that you are running Elasitx? So that means you need 5060 inbound open for your phones by default and 10000-20000 for RTP.
So then it comes to what you need open for the SIP trunk. If it is a registered trunk, you do not need inbound 5060 open to the outside at all, because the trunk will make the outbound registration and the trunk should generally always send incoming call SIP info back on that existing connection. If it is not a registered trunk, then yeah you will need 5060 open to their IP.
The RTP again cannot be outside of 10000-20000 unless you have modified your Elastix install because Asterisk will not recognize anything else.
-
@NetworkNerd said:
@Minion-Queen said:
That's awesome! That will make things much easier.
They can do ip authentication (tie the trunk to a specific public ip) or the standard registration string (whichever you prefer).
How easy is that to change when you need to fail to a DR site
-
@NetworkNerd said:
@Minion-Queen said:
That's awesome! That will make things much easier.
They can do ip authentication (tie the trunk to a specific public ip) or the standard registration string (whichever you prefer).
I know Vitelity offers that now, too. When you authenticate via IP, it utilizes load balancing on their servers. If you just do registry string, once you lock to a server, it's final for the duration of that connection.
-
@JaredBusch said:
Open the entire UDP range above 1024? like WTF kind of generic shit is that?
To me, that right there is a red flag. This provider cannot be serious if they cannot provide specific port information.
I believe that you are running Elasitx? So that means you need 5060 inbound open for your phones by default and 10000-20000 for RTP.
So then it comes to what you need open for the SIP trunk. If it is a registered trunk, you do not need inbound 5060 open to the outside at all, because the trunk will make the outbound registration and the trunk should generally always send incoming call SIP info back on that existing connection. If it is not a registered trunk, then yeah you will need 5060 open to their IP.
The RTP again cannot be outside of 10000-20000 unless you have modified your Elastix install because Asterisk will not recognize anything else.
They did provide specifics. They said open UDP 1024 - 65535 for RTP traffic specifically but UDP 5060 for SIP.
Yes, we are running Elastix and tweaked the RTP range on the PBX to match 1024 - 65535 (recommended by their support team). It's not a registered trunk (just ip authentication).
I can literally create a new trunk in the Intelepeer portal and change my routing profile so that all traffic moves to the secondary trunk in the event my PBX tanks. I can change the routing profile at any time, create a trunk at any time, etc.
-
@art_of_shred said:
@NetworkNerd said:
@Minion-Queen said:
That's awesome! That will make things much easier.
They can do ip authentication (tie the trunk to a specific public ip) or the standard registration string (whichever you prefer).
I know Vitelity offers that now, too. When you authenticate via IP, it utilizes load balancing on their servers. If you just do registry string, once you lock to a server, it's final for the duration of that connection.
Some providers will even let you register multiple PBXs at once with their registration string (NexVortex).
-
@NetworkNerd said:
They did provide specifics. They said open UDP 1024 - 65535 for RTP traffic specifically but UDP 5060 for SIP.
No, stating 1024-65535 is NOT specifics. It is a cop out.
-
@JaredBusch said:
@NetworkNerd said:
They did provide specifics. They said open UDP 1024 - 65535 for RTP traffic specifically but UDP 5060 for SIP.
No, stating 1024-65535 is NOT specifics. It is a cop out.
Well, by the time I knew the port range I had no choice but to make it work because the port orders were in place, LOAs submitted, and contract with the losing provider was almost up (i.e. almost roped into auto-renew). But I understand what you mean about that port range being excessive.
-
@JaredBusch said:
@NetworkNerd said:
They did provide specifics. They said open UDP 1024 - 65535 for RTP traffic specifically but UDP 5060 for SIP.
No, stating 1024-65535 is NOT specifics. It is a cop out.
At that point, why not just completely make it unsecured and put in an any/any rule.
I would silo that shit pronto, so when the inevitable pwnage happens it doesn't infect the rest of the network.
-
@PSX_Defector said:
@JaredBusch said:
@NetworkNerd said:
They did provide specifics. They said open UDP 1024 - 65535 for RTP traffic specifically but UDP 5060 for SIP.
No, stating 1024-65535 is NOT specifics. It is a cop out.
At that point, why not just completely make it unsecured and put in an any/any rule.
I would silo that shit pronto, so when the inevitable pwnage happens it doesn't infect the rest of the network.
If it's limited only to the IP of the SIP provider, what are you worried about? Don't get me wrong, we should of course limit the ports when possible, but really 1 port versus 64K ports - does it make you more vulnerable when you've locked the ports to a single incoming IP?
-
@Dashrender said:
@PSX_Defector said:
@JaredBusch said:
@NetworkNerd said:
They did provide specifics. They said open UDP 1024 - 65535 for RTP traffic specifically but UDP 5060 for SIP.
No, stating 1024-65535 is NOT specifics. It is a cop out.
At that point, why not just completely make it unsecured and put in an any/any rule.
I would silo that shit pronto, so when the inevitable pwnage happens it doesn't infect the rest of the network.
If it's limited only to the IP of the SIP provider, what are you worried about? Don't get me wrong, we should of course limit the ports when possible, but really 1 port versus 64K ports - does it make you more vulnerable when you've locked the ports to a single incoming IP?
My response to that is how can I trust them to keep their stuff secure when they cannot even configure a proper set of ports for RTP?
-
@JaredBusch said:
@Dashrender said:
@PSX_Defector said:
@JaredBusch said:
@NetworkNerd said:
They did provide specifics. They said open UDP 1024 - 65535 for RTP traffic specifically but UDP 5060 for SIP.
No, stating 1024-65535 is NOT specifics. It is a cop out.
At that point, why not just completely make it unsecured and put in an any/any rule.
I would silo that shit pronto, so when the inevitable pwnage happens it doesn't infect the rest of the network.
If it's limited only to the IP of the SIP provider, what are you worried about? Don't get me wrong, we should of course limit the ports when possible, but really 1 port versus 64K ports - does it make you more vulnerable when you've locked the ports to a single incoming IP?
My response to that is how can I trust them to keep their stuff secure when they cannot even configure a proper set of ports for RTP?
You have a completely valid point.
Setting that aside - does the rest of my point remain valid?
-
@Dashrender said:
@JaredBusch said:
@Dashrender said:
@PSX_Defector said:
@JaredBusch said:
@NetworkNerd said:
They did provide specifics. They said open UDP 1024 - 65535 for RTP traffic specifically but UDP 5060 for SIP.
No, stating 1024-65535 is NOT specifics. It is a cop out.
At that point, why not just completely make it unsecured and put in an any/any rule.
I would silo that shit pronto, so when the inevitable pwnage happens it doesn't infect the rest of the network.
If it's limited only to the IP of the SIP provider, what are you worried about? Don't get me wrong, we should of course limit the ports when possible, but really 1 port versus 64K ports - does it make you more vulnerable when you've locked the ports to a single incoming IP?
My response to that is how can I trust them to keep their stuff secure when they cannot even configure a proper set of ports for RTP?
You have a completely valid point.
Setting that aside - does the rest of my point remain valid?
Yes, as long as you have properly restricted it to the provider, you have less to worry about.
-
@JaredBusch said:
@Dashrender said:
@JaredBusch said:
@Dashrender said:
@PSX_Defector said:
@JaredBusch said:
@NetworkNerd said:
They did provide specifics. They said open UDP 1024 - 65535 for RTP traffic specifically but UDP 5060 for SIP.
No, stating 1024-65535 is NOT specifics. It is a cop out.
At that point, why not just completely make it unsecured and put in an any/any rule.
I would silo that shit pronto, so when the inevitable pwnage happens it doesn't infect the rest of the network.
If it's limited only to the IP of the SIP provider, what are you worried about? Don't get me wrong, we should of course limit the ports when possible, but really 1 port versus 64K ports - does it make you more vulnerable when you've locked the ports to a single incoming IP?
My response to that is how can I trust them to keep their stuff secure when they cannot even configure a proper set of ports for RTP?
You have a completely valid point.
Setting that aside - does the rest of my point remain valid?
Yes, as long as you have properly restricted it to the provider, you have less to worry about.
I've restricted SIP and RTP traffic to the Intelepeer ips as @Dashrender mentions.
