Avaya IP Office Server Edition - Part III
EM: I’m EM with Digitcom Canada.
JW: And I’m JW with Digitcom.
EM: Today, we’d like to lead you through Preferred Edition, small community network, and the resiliency options that are available on 9.1. JW, correct me if I’m wrong on any of these.
EM: First of all, I’m just going to draw some sites here. VAN for Vancouver, CAL for Calgary and let’s say Toronto – TOR for Toronto. And in Vancouver, we’ve got a standard IP Office 500V2; Calgary, the same thing; and of course, same thing in Toronto. Each of these sites is running IP phones, and that’s kind of important. Because from a resiliency standpoint, digital phones clearly can’t look to another site in the case that a site goes down, because they are connected to a digital station module, which is part of the site that went down. So, these are all IP phones.
JW: So, only IP phones can failover, digital phones cannot?
JW: Okay. So we have three separate cabinets: Site 1, Site 2, Site 3. They’re all separately programmed, all have their own information, all with IP phones in this picture.
EM: Exactly, for sure.
EM: And very fortunately, our customer is attached through the internet. They’ve got either MPLS or maybe a VPN, but we can say that each site has full visibility of one another. And that’s important because what I’d like to do is, I’d like to devise a trunk from Vancouver to Toronto, and from Calgary to Toronto, and from Calgary to Vancouver.
JW: And why are you doing all of these trunking?
EM: That’s a good question. Here, let me tell you why. The voicemail server is going to be here in Toronto, and I’d like to, somewhere in the future, introduce a second voicemail server as well. But right now, I only have one voicemail server and it’s connected in Toronto. What I would kinda like happen here, is if one of our sites should go down, if one our lengths, say the length between Toronto and Calgary goes down, the link between Toronto and Vancouver goes down, I would like for Toronto’s phones to be able to failover to a correct adjacent site.
So, say for example, Vancouver. Vancouver here is closer geographically to Calgary, and maybe we’ve got a more reliable link between the two of them than we do between Vancouver and Toronto. I’d like for Vancouver’s phones, let’s just put a line number on this because it’s easier for me, line number here. So this is 992.
JW: So, what does this mean? 991/92?
EM: I’ll explain. These phones here can each be set up to go to a specific line. So anywhere where we have a connection, we can say those phones could fail too. So, in other words, because Calgary has IP phones, it has licensing for them, Vancouver has licensing for IP phones and so does Toronto. In the case that Vancouver’s system died for some reason, we can send each of these phones to either Calgary or Toronto depending on which line we set these phones up to, which gives up some nice geographic options. Because again, maybe our link to Toronto is too slow, so we’re going to get too much jitter [with these phones 00:03:32].
JW: So this phone system over here can act as 100 percent failover for these handsets over here?
EM: That’s right.
JW: If cabinet dies, all these phones can re-authenticate to that cabinet.
EM: That’s right. And they do that license free, which is nice. So, these phones are all licensed to the Vancouver–
JW: Will you need a networking license on each system in order to make this happen?
EM: Exactly, but that’s it. The phones otherwise authenticate to Calgary and they get loaded on by Calgary and held there until the Vancouver system’s back in place again. So, the phones sit on your desktop and they still work properly, and yet the IP Office for whatever reason is down. Even during an upgrade, the phones can authenticate to Calgary and keep your business going while you upgrade its system, which is pretty remarkable.
So, the difference of course between creating one line and two lines, is it gives us more choices as far as where we would —
JW: So this system, Vancouver can fail to Calgary, or it can fail to Toronto.
EM: That’s right. In fact…
JW: And the same thing with Toronto can fail to Calgary or Vancouver, so all three sites can fail essentially to each other.
EM: That’s right.
JW: Now, that presumes that if you have a firewall here and this box dies, these handsets have lost connectivity to the outside world entirely. So if you’ve got a router in here…
EM: But theoretically, your IP Office V2 is out by that time, right? So the handsets are still okay and maybe even your local telco’s okay, but you’ve lost connectivity to the voicemail server and you lost connectivity to the other sites.
JW: That’s right. So, as long as you have proper lines coming in: SIP trunks, PRI, analog lines, so this would be your lines.
EM: As long as you have Local PSTN.
JW: Local PSTN, this phone system can operate independent. Now, let’s say, can we introduce voicemail to this equation? So, let’s say your voicemail really is that box right over there, what happens to voicemail for these users over here?
EM: These guys are gone because, again, we had a problem with their firewall, right? So, they have no voicemail at the moment. Now, if we wanted to, we could introduce a second voicemail server, we could introduce a backup voicemail server to that particular system. So, that system could have its own voicemail server, that not only backs up this voicemail, we’ll call it ‘backup’, but in the case that the link to the main voicemail server goes down, that system can talk to the backup voicemail.
JW: Right, okay. Well, you really only have one voicemail system in your small community network, one voicemail fails, this one can act as a backup.
EM: That’s right.
JW: But it’s never really live. It only turns on or essentially becomes alive once we have a problem. Now, what happens with voicemail messages so… That’s your primary, if that dies, this becomes your backup. What happens to your voicemail messages when that turns back on?
EM: They get proliferated back to the main one.
JW: Everything’s already back there? Voicemail message, waiting lights work properly, all your voicemail messages are there so you don’t lose anything from a redundancy point of view.
EM: That’s correct, yes.
EM: It is about as good as it sounds. Now, if this guy goes out of the equation for some reason, then the Toronto system continues to be the host of voicemail except Toronto talks to the voicemail server in Calgary. So as strange as it sounds, if either one of them go out, you’re fine. The only way that we could possibly have a problem is if Calgary got completely disjoined from the small community network somehow.
JW: But what difference would that make even if Calgary just joined, this system, so Vancouver, can still see the Toronto system.
EM: Exactly. It’s just Calgary would be out on their own in this case. It can’t be perfect exactly.
JW: Good, okay. I guess that wraps it up.
EM: It does. So, that is our resilience for 9.1 small community networking.
JW: I’m JW.
EM: I’m EM.
JW: And thanks for watching.
EM: Thank you.