We're here talking with Jerry Steinhauer, Chief Technical Officer at Singlewire.
Welcome, Jerry.
Thanks, Brad.
We're here today to talk about the Paging Gateway, the new Singlewire Paging Gateway that will be introduced here in the next few weeks or so.
And you're here to talk about that.
Can you tell us a little bit more about why we're talking about it and what it is?
Sure.
We're really excited to kind of enter this, this new stage in our product development, but before I can really talk about what the Paging Gateway is let me give you a little bit of background.
So, multicast has always been a building block of our scalable paging solution.
So, what that means is when InformaCast triggers a broadcast, each device is going to receive that broadcast by joining a multicast group, and this is really efficient.
This allows a single multicast talker on the network to send to tens or hundreds or even thousands of phones or speakers simultaneously so it's very scalable.
We believe very strongly in multicast as a protocol, and we've been able to build very large installations for our customers as a result.
But the downside is that there are some customers who can't run multicast on their networks, and as a result can't take advantage of InformaCast.
The big example here is managed MPLS networks.
So, some customers can have outsourced the setup and maintenance of their wide area network to a service provider.
And when some of these customers ask their service providers to configure multicast the service provider says, "No, sorry, we're not going to do that," "We're going to make this cost-prohibitive for you because we really don't want to do that."
And so, these customers have been unable to participate in InformaCast historically.
What the Paging Gateway does is to transmit multicast over parts of the network that don't support it.
So the example that I just used was the wide area network.
We're really excited to release the Paging Gateway because it addresses this particular pain point for our customers.
Now, how will this be used?
You talked about a network or campus. Are you talking connecting buildings between places within a city, or even over a larger geography like a couple states?
A branch office, central office type set up?
So if you, if you think about your network in terms of islands of multicast. Going back to the generic example I used earlier--if there's an InformaCast server at headquarters, and the wide area network is unicast only, then the main site and each of the remote sites would be considered a multicast island.
They can talk multicast in locally, within each part of that network.
So within headquarters, you can talk multicast to other devices, but multicast doesn't pass over the wide area network.
So, really you, you think about this in terms of islands of multicast within your your larger network.
So, the headquarters would be an island, and each remote would be an island in this hypothetical situation.
Now, how would a customer use Paging Gateway?
So, basically the way this works, the way we envision this working, is to install InformaCast at the headquarters site, install a Paging Gateway at each remote site, then we go through some configuration on the InformaCast side.
And so, when InformaCast sends a broadcast, it's going to send that audio as a Unicast to the Paging Gateway.
So, InformaCast to the main site, originates that audio as Unicast traffic, sends it over the wide area network, and then the Paging Gateway turns that back in to multicast for phones or speakers at that site.
Now where is the Paging Gateway run?
So, the Paging Gateway is going to be installed at each of those multicast islands.
So, we, in our hypothetical example here, we would install Informacast at the headquarter site and the Paging Gateway at each of the remote sites.
Okay, and what makes up the Paging Gateway?
Are there, is this an appliance or software, how does this work?
Great question.
So, to begin with, the Paging Gateway does require Informacast 8.0, which we just released in the last few weeks and this is because the Paging Gateway is, on the InformaCast side, considered a plugin.
And the plugin architecture, as most of our customers will probably know, is new with Informacast 8.0.
So, the, on the Informacast side, we do require 8.0, because that's a, that's a plugin.
As far as what the Paging Gateway is, let's kind of break that down.
At the top level, there's a Paging Gateway application, and this is a web-based application.
So the application, this is code that software that we supply that connects to InformaCast at the headquarter's site.
Underneath the application is a Paging Gateway operating system.
And in this release, this is Linux.
And just to avoid confusion because some customers have said, "Oh, you're supporting Linux, so that must mean you're not supporting Windows for InformaCast."
This is... All we're really talking about here is the Paging Gateway operating system.
So, the Paging Gateway OS is Linux-based.
We're going to continue supporting Windows for the InformaCast
So some customers could ask, "Why would you choose for an application like this?"
And, two reasons.
The first is stability.
Because since this is part of your emergency broadcast infrastructure, we want to make sure that Paging Gateway at a remote site is as rock-solid as InformaCast is at your main site.
And the second is that it's good fit for the hardware that we've chosen.
And it can scale up from very small environments with limited CPU resources up to very large environments with multiple machines and many more resources.
So, underneath the Paging Gateway operating system is sort of, the Paging Gateway server.
And we're offering two options here, because we like to give customers choices depending on what their infrastructure looks like. That server can either be physical device or a virtual device.
The physical server is a, it's a very small box, it's about six inches by eight inches by one inch.
It's a single board computer with ethernet port on it.
And we chose the single board computer, because it has low power consumption.
It's going to be easy to install.
You don't have to have a 19-inch rack to install your Paging Gateway into.
This is a really a first for us, as far as offering a physical device.
We hope that's for some customers, but we also recognize that some customers are really excited about virtualization because this allows them to choose what server platform they run the application on.
So we are also offering the Paging Gateway as virtual server, and what this will be distributed as is a VM Ware image.
We're very excited to support VM Ware ESX and VM Ware ESXI in this release.
Customers who aren't familiar with VM Ware may know that VM Ware ESXI is free.
So the VM Ware is a no cost option for you, some customers may say well, we want to run, we want to test using VM Ware products like Player or VM Ware server to try the Paging Gateway in our lab.
And that's perfectly okay.
But just to be clear, we're only supporting VM Ware ESX and ESXI for production loads.
And that's in line with what VM Ware recommends, as well.
So a branch office, remote
location is either going to see an appliance that they can purchase, or, if they have an option to put a virtual server in, they could put it right on there.
You bet.
And then be able to the web portal admin that you had mentioned, and be able to get into configuring the system with InformaCast.
You bet.
So really the, if the choice is physical or virtual, really the user experience is the same.
The Paging Gateway works the same whether it's physical or virtual.
It configures the same whether it's physical or virtual.
It's really just an administrative choice, in terms of what makes sense for that particular customer.
Very good.
What impact does this having, you know, running Paging Gateway on a network have on, on a customer's network?
So this, this can get into some network sizing issues and, and I don't want to get too far off in the weeds, but I do want to mention that we do have options for how that voice stream gets sent over the network.
That can either be done as a G.711 stream or a "speaks"
So G.711 consumes about 80K per second and Speaks consumes somewhere around 24K per second. So, depending on the customer's infrastructure between these multicast islands, the customer can determine, which will give them the results that they want given their amount of bandwith that's available and latency.
Basically, the trade off there is G.711, its higher bandwidth, its lower CPU consumption for us.
Whereas, for Speaks, Speaks requires more for us to do that job because what we're doing under the covers is translating G.711 into Speaks to send that out.
So the trade-off there is lower bandwidth consumption over the WAN, higher CPU utilization on the Paging Gateway, and on the InformaCast server.
So there's some trade offs there, but we feel what's important to provide choices for our customers, because it allows
our customers to deploy InformaCast in more diverse environments.
Very good.
So just to play this back, what this Paging Gateway is giving us is the ability to pass multicast or put it into a unicast stream, pass it over the WAN, to a remote location.
And there we essentially unpack it with the Paging Gateway on the other side.
A virtual machine or an appliance that can then reach Cisco phones over at paging systems in that remote location.
That's absolutely right.
I do want to add one more tag to that.
And that is to say that the Paging Gateway also allows, you mentioned Cisco phones specifically, the Paging Gateway also allows to deploy IP speakers at remote locations.
Historically, we required multicast over the WAN to make those work.
The Paging Gateway allows you to register IP speakers at remote sites, to InformaCast at the main site.
So, again, another choice for deployment in diverse environments.
Very good.
Jerry, this is coming out in next few weeks, so...
Yes, indeed.
You know, watch singlewire.com for updates there, we're really excited about this.
We'll be putting more information on the website at singlewire.com/ paging-gateway.
And so, stop by there to see what 's going on.
Jerry, thanks again.
Thanks, Brad.