Similar to e-mail servers, you will need to specify which server would serve a specific domain. The location of the SIP servers is described in RFC 3263. The first objective of location is to determine the IP, port, and transport protocol for the server based on the domain name. The second objective is to determine the address of a backup for the first proxy.
To perform these objectives, we will use a Domain Name System, more specifically, Name Authority Pointer (NAPTR) and Service (SRV) records. NAPTR records are employed to determine the transport protocol. To specify a transport protocol, you should insert the DNS records in the zone file of your DNS server. (Check the documentation of your DNS server on how to do it.) In the following code, we are enabling three protocols for this domain, TLS, TCP, and UDP. If the client supports TLS and UDP, TLS will be chosen because of the defined order in the records:
Order pref flags service regexp replacement IN NAPTR 10 50 "s" "SIPS+D2T" "" _sips._tcp.opensips.org. IN NAPTR 20 50 "s" "SIP+D2T" "" _sip._tcp.opensips.org. IN NAPTR 30 50 "s" "SIP+D2U" "" _sip._udp.opensips.org.
After selecting the transport protocol, it is time to select the preferred server, which is done as follows:
Service TTL Class P/W Port Server _sips._tcp.opensips.org. 86400 IN SRV 0 5 5060 sipA.opensips.org. _sips._tcp.opensips.org. 86400 IN SRV 0 5 5060 sipB.opensips.org. _sip._udp.opensips.org. 86400 IN SRV 0 5 5060 sipA.opensips.org. _sip._udp.opensips.org. 86400 IN SRV 0 5 5060 sipB.opensips.org.
The terms in the preceding code are described as follows:
Service: The symbolic name of the desired service
TTL: The standard DNS time to live field
Class: The standard DNS class field (this is always
IN
)Priority: The priority of the target host; a lower value means more preferred
Weight: A relative weight for the 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
The configuration of the SRV records is often used to provide failovers and load sharing between the SIP servers. It is one of the easiest ways to get geographical redundancy in a SIP project.