SR140 DNS query support with SRV

Today SR140 supports only DNS A type query for IPv4. SIP Trunk service provider use SRV (Service Record) in order to hide the farm of SIP Server behind a DNS load balance.

The Domain Name System (DNS) associates various sorts of information with domain names; most importantly, it severs as the "phone book" fr the internet by converting human-readable complete hostnames (www.dialogic.com) to the IP address (192.168.102.14).  

The DNS distributes the responsibility for assigning domain names and mapping them to IP networks by allowing the authoritative server for each domain to keep track of its own changes, avoiding the new for a central registrar to be continually consulted and updated.  An SRV record or Service record is a category of data in the Domain Name System specifying information on available services. It is defined in RFC 2782.

An SRV record has the form:

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

Service: The symbolic name of the desired service.
Proto: The protocol of the desired service; this is usually either TCP or UDP.
Name: The domain name for which this record is valid.
TTL: Standard DNS time to live field.
Class: Standard DNS class field (this is always IN).
Priority: The priority of the target host, lower value means more preferred.
Weight: A relative weight for records with the same priority.
Port: The TCP or UDP port on which the service is to be found.
Target: The canonical hostname of the machine providing the service.

An example SRV record might look like this using bind syntax:

_sip._udp.carrier.com. 86400 IN SRV 0 5 5060 sipserver.carrier.com

This points to a server named sipserver.carrier.com listening on UDP port 5060 for SIP protocol connections. The priority given here is 0, and the weight is 5.
With SIP telephony, a SIP call might start as 7814339255@dialogic.com for the call to proceed, the phone needs to locate the IP address for dialogic.com by using a DNS query. 

FAILOVER SBCS WITH DNS SRV

The priority field is similar to an MX record’s priority value. Clients always use the SRV record with the lowest numbered priority value first, and only fall back to other records if the connection with this record’s host fails. Thus, a service may have a designated “fallback” server, which will only be used if the primary server fails. Only another SRV record with a priority field value higher than the primary server’s record is needed. 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.
In failover, SBCs are set with different priorities. The lower priority SBC is tried first, and if that SBC is unavailable, the SBC with the higher priority is tried. Records with higher priority values are only tried if all records with a lower priority are considered unreachable. 

In the following example, DNS SRV record query to carrier.com with both the

_sip._udp.carrier.com 60 IN SRV 10 50 5060 sbc1.carrier.com
_sip._udp.carrier.com 60 IN SRV 20 50 5060 sbc2.carrier.com

DNS A Record Query yields:

sbc1.carrier.com = 10.10.0.10
sbc2.carrier.com = 10.10.0.20

If the server with the priority 10, sbc1.carrier.com is unavailable, the record with the next higher priority would be chosen, which would be sbc2.carrier.com.

LOAD BALANCING SBCS WITH DNS SRV

In the following example, a DNS SRV record query to carrier.com with both the priority and weight fields each with 50% of the traffic load is used to provide a load balancing and backup service and would yield:

_sip._udp.carrier.com 60 IN SRV 10 50 5060 sbc1.carrier.com
_sip._udp.carrier.com 60 IN SRV 10 50 5060 sbc2.carrier.com
_sip._udp.carrier.com 60 IN SRV 20 0 5060 backupbox.carrier.com

If one SBC becomes unavailable, the remaining machine takes the load. The two records share a priority of 50, so the weight field’s value will be used by clients to determine which server (host and port combination) to contact. The sum both values is 100, so sbc1.carrier.com will be used 50% of the time and sbc2.carrier.com will be used 50% of the time. DNS A Record Query yields:

sbc1.carrier.com = 10.10.0.10
sbc2.carrier.com = 10.10.0.20

If both servers with priority 10 are unavailable, the record with the next highest priority value will be chosen, which is backupbox.carrier.com. This might be a machine in another physical location, presumably not vulnerable to anything that would cause the first two hosts to become unavailable. Several implementations relying on DNS also automatically update the DNS servers to optimize the load of servers or to remove servers due to service failures.