| Page Properties | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
- Add support for RFC 2782 - A DNS RR for specifying the location of services (DNS SRV).
Glossary
DNS - Domain Name System
RR - Resource Record
SRV - Service Record
Background and strategic fit
Today SR140 supports only DNS A type query for IPv4 and AAAA for IPv6. SIP Trunk service provider use SRV (Service Record) in order to hide the farm of SIP Server Servers behind a DNS load balance.
The Domain Name System (DNS) associates various sorts of information with domain names; most importantly, it severs serves as the "phone book" fr for the internet by converting human-readable complete hostnames (www.dialogic.com) to the an 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.
Use Cases for SRV
The following sections define use cases for using SRV. These cases show how SRV can be deployed to allow flexable deployments. The usage of SRV allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and to designate some hosts as primary servers for a service and others as backups.
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
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 5010, 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.
...
| # | Title | User Story | Importance | Notes | |
|---|---|---|---|---|---|
| 1 | Support SRV Record Query | The SR140 will add support for sending an SRV DNS request. | Must Have | ||
| 2 | TCP and UDP mode | Support for querying SRV records for both TCP and UDP over SIP mode based on the SR140. This is based on the users sip_transport_protocol setting in the [host module.x/parameters] section of the callctrl.cfg file. | Must Have | ||
| 3 | Priority | The SR140 must attempt to contact the target host with the lowest-numbered priority it can reach | Must Have | ||
| 4 | Weight | The SR140 target hosts with the same priority, the selection will be performed by the weight field. | Must Have | ||
| 5 | DNS A | Based on the selected target, the SRV record may or may not have provided a DNS A record. If it available, the SR140 should used the provided record. If it is not available, the SR140 should query DNS for the A record of the target host. | Must Have | ||
| 6 | No response | If there the remote does not respond the the SRV request or returns a not support type response the SR140 will use the appropriate DNS A query as currently implemented. | Must Have | ||
| 7 | Configuration | There will be no required configuration setting for this feature and it will be enabled by default. | Must Have | 8 |
User interaction and design
None should be required.
...
Test Scenarios
From Bob:
User interaction and design
None should be required. They should show cases where the SRV information provides the DNS A information and cases where we'd query for the DNS A information. We should make sure that if SRV is not supported that DNA all by itself still works. We should verify that the target host with the lowest priority is used and that the weight value is followed for cases of equal priority.
Questions
Below is a list of questions to be addressed as a result of this requirements document:
...