Burned by Eschewing Best Practices
-
I can see why you woudn't want to bundle different services together into one contract. But that's not the same thing as having the same provider for different, independent services.
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
I can see why you woudn't want to bundle different services together into one contract. But that's not the same thing as having the same provider for different, independent services.
It's true, they are not one and the same thing. One is a bundle, one is not. Separate contracts are far better, but generally it is the assumed value of bundling that causes the situation, rather than the other way around.
That's a unique situation that I've literally never heard of happening. Still caries the risks, though, just not quite as badly. How do you failover to another site if your ISP fails? How do you failover to another site if your site fails or PBX? How do you move your PBX to another location or go to hosted? If you have separate contracts, how do you receive your VoIP if your ISP is gone?
-
If you have separate contracts, do you have the same vendor blaming other parts of the same vendor for issues? Like your ISP goes down, so the SIP contract side says that it isn't their problem because your ISP failed, even though it is the same company?
-
I would imagine so, yes.
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
Obviously telecoms various work differently in different countries, so maybe there isn't a standard rule?
Some countries, like Oman, ban non-monopoly telephony services. This would apply to any free market country.
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
I would imagine so, yes.
So one company can cut service and even with only one throat to choke, you get the blame game and no one to hold responsible. That's scary. They can use that as a way to not deliver on SLA.
-
@Dashrender said in Burned by Eschewing Best Practices:
Here is my setup, which is fairly unique.
cable modem connection to the internet 100/20 - no contract, pay month to month
SIP trunks, these are delivered over an onsite fiber connection between me and that same ISP. The ISP has a SIP Gateway device onsite that they connect to, then there is an ethernet connection on gateway device that connects to my PBX. I pay a flat fee for unlimited local calling, and a per/min fee for long distance. - no contract, pay month to month
This is not unique. This is quite common.
This is also quite a large issue when people have problems.
-
How is it different if, say BT provide the SIP trunks, and TalkTalk provide the leased line?
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
How is it different if, say BT provide the SIP trunks, and TalkTalk provide the leased line?
Because the SIP trunks are not tied to your line. You can run the SIP trunk on any line you get from any provider.
-
But they're not tied currently. I can run my SIP trunk on any line from any provider, I just happen to use BT.
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
How is it different if, say BT provide the SIP trunks, and TalkTalk provide the leased line?
Freedom, flexibility, protection. For example, my SIP trunks come from voip.ms. I can access this from anywhere, over any ISP. So I get the ability to failover my ISP if one fails, or to switch ISPs if I want. I can failover to another site, or move to hosted. I can even fail from country to country (tested and works.)
The difference is... is your phone delivered as part of physical infrastructure or is it a modern Internet service.
VoIP only denotes voice over IP protocol, but most people intend this to mean modern telephony delivered over the Internet as a converged service.
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
But they're not tied currently. I can run my SIP trunk on any line from any provider, I just happen to use BT.
Then you are not in the position that 'the rule' is talking about.
Almost everyone in the US that buys a SIP trunk from their provider is like @Dashrender. The SIP trunk only runs over the providers pipe.
-
@Dashrender said in Burned by Eschewing Best Practices:
A more normal SIP delivery solution is as follows:
You purchase Internet connection from and ISP.
You purchase SIP trunks from a SIP provider different from your ISP.
The SIP trunks are delivered over your ISP connection via the internet.
If your Internet connection goes down, you can use a different internet connection to bring the SIP trunks into your location, for example, your cell phone, and your calls could resume working.
This is a very simplistic explanation.
That's the good way, but I'm not sure it's normal. I think your way might be the most common.
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
Why would it affect the other? They're separate services, that just happened to be with the same provider.
Are they truly separate? That's not available in the US AFAIK. So, for example, you could give me your BT credentials and I could hook up your BT line to my PBX?
-
@scottalanmiller said in Burned by Eschewing Best Practices:
@Carnival-Boy said in Burned by Eschewing Best Practices:
Why would it affect the other? They're separate services, that just happened to be with the same provider.
Are they truly separate? That's not available in the US AFAIK. So, for example, you could give me your BT credentials and I could hook up your BT line to my PBX?
Well, BT SIP could have country IP blocking going on, so that's not a completely known good test... but it would be a starting point.
Scott's right - Are you SURE you can run the SIP over any ISP connection, from any available to you ISP?
-
@scottalanmiller said in Burned by Eschewing Best Practices:
Are they truly separate? That's not available in the US AFAIK.
Why not?
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
@scottalanmiller said in Burned by Eschewing Best Practices:
Are they truly separate? That's not available in the US AFAIK.
Why not?
Because people don't know better. Most buying services are just looking to the old timie solution providers like Qwest and AT&T. And those providers often demand a dedicated line to you to provide those services.
-
So you're saying the rule is that your internet pipe/leased line should be a separate contract to your SIP trunk. Company A (let's call them 'BT') sell leased lines and SIP trunks. Company B (let's call them 'TalkTalk') also sell leased lines and SIP trunks.
You should buy one service from BT, and one from TalkTalk. That's the rule, right? So TalkTalk are happy to run their SIP trunks on BT's leased line, and vice versa? The two are independent.
But if you buy both services from the same provider, their automatically tied together, and you can never separate them? That doesn't make sense?
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
So you're saying the rule is that your internet pipe/leased line should be a separate contract to your SIP trunk. Company A (let's call them 'BT') sell leased lines and SIP trunks. Company B (let's call them 'TalkTalk') also sell leased lines and SIP trunks.
You should buy one service from BT, and one from TalkTalk. That's the rule, right? So TalkTalk are happy to run their SIP trunks on BT's leased line, and vice versa? The two are independent.
But if you buy both services from the same provider, their automatically tied together, and you can never separate them? That doesn't make sense?
Well in the US, assuming Company A is an ISP, Company A does not sell SIP service unless is on a line from Company A.
You cannot even buy SIP service from Company A to run over a line from Company B.
On the other hand, Company B does let their SIP service run on any line. So you can get separate services with SIP from Company B and a line from Company A.
-
@Carnival-Boy No what @scottalanmiller and @JaredBusch are saying is if you are buying SIP service from a vendor, you should be allowed to access that service from any Internet service provider in the world.
If you can't then you are locked in such a way that if you lost your internet, you'd also lose your phone service.
