Potential New SIP Providers - Thoughts?
-
We did an interop with Intelepeer on Monday night to ensure we had our firewall and PBX configured properly. They suggested we open UDP 1024-65535 on the Asterisk box so there would be no issues with RTP traffic getting blocked. We did that and locked down the firewall to only their signaling and media ips.
The numbers ported yesterday afternoon. Thus far we've cleared up 3 issues we had with Broadvox Fusion just by making a switch (some issues faxing outbound / receiving faxes inbound using G711u, issues calling the toll free number of our payroll company, and issues with dropped calls / one way audio when using follow me).
Fusion called me to ask why we chose to left, and I gave them blunt honesty. I told them their tech support for anything non-mission critical was very poor and that my experience was having to call multiple times (2 or 3 along with e-mail traffic) to get on the phone with a technician to help troubleshooting. They also make it a pain to terminate services. You cannot call their terminations department to get information about fees to terminate, etc. Customer Service tells you to e-mail the terminations department, and you may or may not get a response for a few days. It really does not help when you need information quickly.
Intelepeer support calls go straight to the NOC. A real person answers the call immediately. It's easy to create port requests in their online portal and upload the necessary information. You can request new numbers very easily or add features to existing numbers. I am really liking it thus far.
-
Glad to hear it went well. We will be looking into them for some clients.
-
@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.
