VOIP Tech Chat → Re: Where are the SERVERS ? - Summary

I think counting and listing server locations is based on a noble idea, but not likely to capture or characterize the systems in a meaningful way to customers.

Customers are interested in the reliability and availability of the services they've purchased. Let's begin with two simple definitions so we're all talking the same language.

Reliability: How often I can expect something to fail (or be unavailable) in a specified period of time.

Availability: What percentage of time I can expect something to be working. The standard availability formula is:
availability = uptime / (uptime + downtime)

Those are not two terms for the same thing. Something that fails 10 times a year for one minute each time has the same expected availability as another thing that fails once per year, but is out for 10 minutes. Their reliability is different, though.

VoIP customers are usually primarily interested in the reliability and availability of three things:

1. The ability to place outgoing calls from my phone.

2. The ability to receive incoming calls to my DID.

3. The ability to provision or make changes to account account/service.

There are other things, but those are the big three. Different customers will put them in different order or place different priorities on them based on their personal or business needs.

A server failure (or any other failure) may affect all of the services I'm interested in or just a subset. There are many failure modes in a distributed architecture.

The number and location of servers are just two of many factors contributing to the reliability and availability of customer purchased services. The design of the servers themselves, the architecture of the overall solution, and the availability of repair/correction staff are among a long list of other factors. Then you have to add in the expected reliability and availability of elements outside of the provider's direct control, such as physical CLEC connections and interconnecting IP networks.

Unfortunately, the detailed data necessary to estimate the expected availability of purchased services isn't readily available, so we're left with personal experience and that of others (word of mouth, reviews, forum info, etc.).

A typical VoIP provider will use several different kinds of servers to perform the various functions. It's unlikely any are using the same physical servers to host their web pages and provisioning as their SIP proxy servers. It's possible to have one web server and numerous SIP proxy servers scattered around or vice versa, although neither configuration makes much practical sense. The point is counting something as generic as "servers" doesn't tell you much about the expected reliability or availability of your DID line.

The bottom line is: does the provider have a disaster recovery plan? Unfortunately Callcentric does not.

Think about this: What would happen if a natural or man-made disaster totally destroyed your provider's central operation.

One example of a good recovery plan is Anveo which has three data centers, widely separated in three different countries.

Your standard formula does't work when a single-site provider is destroyed.

 
Interesting proposal, but I will be lucky to receive the level of info which I requested, never mind the degree of detail required to do calculations as you suggested.

 
.... right, and if yes, then what sort of a plan ?

Essentially that is all I wish to establish at this time.

AND, I am trying to avoid words which are open to misinterpretation, such as some of those contained in CallCentric's self-posted mission statement description on their own site.

One small observation, if you want the security of servers on three sites make sure you specify anveo.com as the proxy rather than sip.anveo.com, sip.ca.anveo.com or sip.de.anveo.com. It's the only SRV record that points to all three servers.

How can the bottom line be anything other than, "do I have the services I paid for?"

A provider can have 100 servers, yet a single failure might render your DID number completely unworkable until it's resolved. Of course having a single server or a single location makes it vulnerable to location-wide disasters that affect all of their services, but that's just one of many failure modes that will affect the services you paid for.

Done, and thanks.

Anveo should document things like this.

One more bottom line:
"Does the customer have a disaster recovery plan?"

Voip is a wonderful service saving us $$$. But IMHO the user needs to have a disaster recovery plan. Having at least one backup voip provider and a cell phone is always a good part of a disaster recovery plan.

Your internet connection could also fail so a backup internet connection should be considered. Your provider can have geo redundancy but that won't help you if your internet connection fails.

Also, an UPS must be considered as mandatory for a responsible voip user.

+1

 
Fixed it for ya !

But seriously, how does one get an SRV record to reveal itself ?

I'm still a N00B on that.

And BTW, then does this observation also imply that if I am in Canada, 2 hours from Montreal, that I should specify ca.anveo.com rather than sip.ca.anveo.com ? (in my ATA)

On test, their Montreal server did yield a notably sharter PING than the next best one (USA) for me.

 
Yes, we all need to practise what some of us so fervently preach.

And yes, I have all of those things, except the 2 ISPs.

Ditto - except for 2 ISPs - have cell phones (that don't work very well in our house). That's why we have Voip.

Two ISP is a bit overkill.
That's the reason why I went to a GSM gateway.

Have you tried using voip through the GSM gateway? If so, how is the quality?

Arne,

Yes I have.
The quality is a good as your normal VoIP. There is time where the system has failed over and I have not even notice.

Thanks, it's interesting info. Are you using 3G or 4G in your GSM gateway?

Arne,

I apologize I miss understood your original question.
I am not actually failing over data. I have a logic that checks for the ITSP availability. It ether returns with a 1 or a 0. 0 Fails over to the GSM gateway and uses the gateway for all outbound calls... The same logic applies from the ITSP's to me. If they see me not register than they send all calls to my GSM gateway. If it returns 1 than the interconnection continues to the ITSP. In my own opinion I didn't find failing over data an actual fail over solution. In case of a natural disaster we are going to be lucky if cell alone works. Back in Ike my cell worked but there was no data going on the network no 3G or 4G but basic incoming and outgoing calls where working.

Thanks. I just thought you used voip over the GSM data connection.

The way you are using the GSM gateway is probably better as you don't risk latency and jitter. I have tested voip over a 3G data connection and I find the quality to be unacceptable for daily use, but it can be used if there are no other options.

No definitely not. It will not work. If you want to prioritise the Canadian server with a fallback of the US server use sip.ca.anveo.com.

Assuming you use Windows, start a cmd window and type nslookup. Then at the prompt type set type=srv, then type _sip._udp.<domain you are interested in>

See the example below.


Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\User>nslookup
Default Server: Default-Server
Address: 192.168.29.1

> set type=srv
> _sip._udp.sip.ca.anveo.com
Server: Default-Server
Address: 192.168.29.1

Non-authoritative answer:
_sip._udp.sip.ca.anveo.com SRV service location:
priority = 20
weight = 100
port = 5010
svr hostname = sip.anveo.com
_sip._udp.sip.ca.anveo.com SRV service location:
priority = 10
weight = 100
port = 5010
svr hostname = sip.ca.anveo.com
>


 
Thanks, and you are right - that one does not register my ATA.

Here is a list of all possible server names and results :

anveo.com - register - 3 servers on nslookup
sip.anveo.com - register - 2 servers on nslookup

sip.ca.anveo.com - register - 2 servers on nslookup
ca.anveo.com - NO register - nslookup says "domain does not exist"

sip.de.anveo.com - register - 2 servers on nslookup
de.anveo.com - NO register - nslookup says "domain does not exist"

OK, so anveo.com gives all 3 servers, each beginning with sip. gives 2 servers, but different combos, and the other choices without the sip. prefix say no good.

My ATA accepts any domain which NSLOOKUP accepts, and registers those choices.

NEXT QUESTION : in the NSLOOKUP output, is 10 a higher priority than 20 ? (and so on) - Instinctively I would have expected the opposite.

Yes, 10 is a higher priority than 20.

Imagine a long queue, if you are number 10 in that queue and your friend is number 20 you will be served before your friend.

 
Ahhhh, thanks.

"Now serving number 83, number 83 please...."

OK, then what does 'weight' do ? (I notice that Anveo sets all of theirs to 100 and that CallCentric always uses 0 for that field.)

Now I think of the TV commercial with the long iPhone queue and the people outside of that queue with Samsung Galaxy phones. The guy in the iPhone queue happily says "Maybe we get that feature next year". Weight: A relative weight for records with the same priority

The priority field determines the precedence of use of the record's data. Clients always use the SRV record with the lowest-numbered priority value first, and fallback to other records of equal or higher priority if the connection to the host fails.

If a service has multiple SRV records with the same priority value, clients use the weight field to determine which host to use. The weight value is relevant only in relation to other weight values for the service, and only among records with the same priority value.

 
So it would seem that 'weight' is a sort of 'fine-tuning' for 'priority'.

Correct. But it is only used among records with the same priority value.

This is a good thread. Recent events have proved that users cannot rely on service reliability statements on a providers web site. Unless they are prepared to go into detail about their network setup and redundancy plans, their sales pitches should be taken with a pinch of salt.

There is a good overview of Priority and weight at »en.wikipedia.org/wiki/SRV_record

I use several providers and so far I have not found any unreliable statements.

Weight allows for you to concentrate traffic on higher power machines.

For example, if one machine was a 2 processor box, and one machine was a 4 processor box, in theory I would want to put 2 times the amount of traffic on the 4P box.

'Weight' allows me to do this.

 
After certain recent events, I am inclined to agree.

Part of this thread's raison d'etre is to point out and clarify such info about common VoIP providers.

And thanks for the link. - I should have thought of that myself, however Arne was handy at the time.