Cloud Computing is a hot topic in the computer and the communications industry these days.  At Dialogic, we’ve seen many application software vendors who want to take advantage of this trend and offer hosted telecommunications services that reside in the cloud.  For example, a conferencing vendor might choose to have a series of application servers to support their conference bridges.  Cloud Computing allows the vendor to have servers on either a centralized or distributed basis, depending upon the best way to serve their customers.   Typically, the conference bridge will be accessible by setting up a communications session via the Session Initiation Protocol (SIP).  

In today’s business settings, conference users may connect either directly via Voice over IP or dial in from a fixed line or mobile phone.  In order to connect to a SIP-based conference bridge, the hosted conferencing vendor will typically use a media gateway, which will connect the incoming call from the circuit network to the gateway and ultimately, connect to a SIP-based application server in the cloud.   Here’s where it gets interesting.   Since conferencing vendors will need to support a wide variety of scheduled and ad-hoc conferences, they want to be able to select an application server which has “conferencing seats” available and not run the risk of overloading the server so that the user won’t be able to connect.   In a typical SIP connection via a gateway, the gateway will send an Invite to a single conferencing server, which will then either accept the invite to allow the connection to the conferencing bridge, or reject it.   This works okay for a small local region, but there’s a chance that one application server will get overloaded and additional users will not be able to sign on.  

This presents a challenge.  Is there a straightforward way to manage multiple application servers and ensure that calls from a single or multiple gateways will not overload the application server?   It turns out that one answer lies in using Internet technology which has been around for quite a few years.   Domain Name Servers (DNS) servers are used throughout the Internet and are the way that web servers can take an incoming web request that uses names and translate that into an IP address.   It turns out that there are many different types of records that can be used on DNS servers.   One of the most useful is the SRV record.    An SRV record can have a number of properties, which can include a priority and a weight.   Through clever use of SRV records, the vendor for the conferencing server in our example can set up an SRV record in a DNS server for each one of its application servers.  

So, perhaps you’re thinking, okay, the conferencing vendor can set up multiple records in a DNS server.  How does that help the gateway to connect to the correct application server?   The key lies in having an integrated media gateway or IP border element which has support for DNS servers and can query the DNS server looking for SRV records.   The conferencing vendor can load up the DNS with a series of SRV records in priority order and also include a weight attribute.   The use of DNS as a kind of gatekeeper allows the conferencing vendor to dynamically manage the entries in the DNS and adjust priorities and weights to enable load balancing between multiple application servers.  

The query by the gateway will return one or more SRV records in priority order, each of which will have an internet address in the form of a hostname (also called a Uniform Resource Locator or URL) or an IP address.   Then, depending upon the arrangement between the conferencing vendor and the gateway, the gateway can attempt SIP invites using the URL retrieved from the DNS server and connect to an available Application Server.  In the event that the first server refuses the connection, the gateway can then drop down to the next server on the list and try for a connection that way.   If a weight is used as part of the selection algorithm, then the weight can be factored in when the gateway makes the decision on which application server to send the Invite to.   A similar approach can be used for all-IP Border Elements, which will need to support the DNS and SIP features I’ve described when connecting IP-based subscribers to an array of application servers in the cloud and may need features like integrated voice transcoding to successfully connect to the conference bridge.   

In this post, I’ve used Conferencing as the service example, but the approach can be equally applicable for a wide variety of Cloud hosted services such as Contact Centers, IP Centrex and Interactive Voice Retrieval (IVR).   At Dialogic, our IMG family of integrated media gateways and border elements support all of the DNS, SIP and transcoding features described in this article.  We have multiple deployments where the IMG helps our application service partners to load balance among multiple application servers and connect subscribers from a wide variety of circuit-switched and IP networks.  

In summary, the widely available DNS server technology can be used by application vendors to enable load balancing between application servers which reside in the IP Cloud and meet the service needs for a large number of users in multiple geographic locations.   This can help application vendors reduce their capital and operating expenses, by reducing the number of servers needed to support their customers and enabling tremendous flexibility when setting up a cloud-based service.  In order to enable circuit switched users to participate in this approach, the application vendor needs to select integrated media gateways that support a wide variety of circuit based protocols, have support for DNS server queries and can integrate the results of those queries with a robust implementation of SIP.   For support of IP-based subscribers, similar benefits can be achieved by utilizing all-IP border elements which include the DNS and SIP features described above.