SIP (Session Initiation Protocol) is an Internet protocol for transferring signals in Internet telephony. It normally uses UDP port 5060, but can also work over TCP/5060. This protocol and other related matters are defined by RFC 3261 and are further modified by other RFCs. In this article, we will not deal directly with this protocol, but we will relate it to domains and DNS.

If we want to make calls to someone over the Internet using some VoIP (Voice over IP) technology, SIP addresses (SIP URIs) in the form sip:name@domain are used to identify the recipient. It is similar to e-mails, the address contains a domain that offers the necessary telephone services (for example, telephone service providers), and some local name that is recognized by the relevant VoIP server. The domain then contains the necessary records in the DNS, which are similar to MX records for e-mails, from which we will find out which server to contact if we want to contact someone from this domain. Thanks to this, it is possible to separate these addresses from the VoIP service provider (when changing providers, only the domain owner will change the relevant DNS record, which will then direct to the servers of the new provider). Specifically, these are SRV records, which are used not only for SIP purposes, and the information for SIP is located on special subdomains _sip._udp.domain or _sip._tcp.domain. The SRV record is specified in RFC 2782.

The SRV record type contains the following information:

• priority – similarly to MX records, the connection is established first with the server with the lowest priority value and another is only tried when the connection is impossible
• weight – the relative weight of the record for records with the same priority
• port number
• target host (domain name)

The above data weight is used to determine what the relative load distribution should be for servers that have the same priority. If, for example, the first record weight is 10 and the second recording weight is 90, the second server will be contacted in approximately 90% of cases and the other in the rest. The disadvantage of this layout is that it is static data that does not reflect the actual current load of those servers. In addition, this distribution is relative only in the case of one contacting client because they can not know what is the frequency of communication from other clients.

To make it clear, we will use the following example to show how we could contact someone via SIP protocol on the nic.cz domain. If you send a request for the “_sip._udp“ subdomain and SRV record type to the DNS server, we will get the following response:

;; QUESTION SECTION:
;_sip._udp.nic.cz. IN SRV

;; ANSWER SECTION:
_sip._udp.nic.cz.   1800  IN  SRV  100 100 5060 sip.nic.cz.

From the responses we will learn that we have to contact the SIP server sip.nic.cz on UDP port 5060. SRV records have many other uses. For example, Microsoft Windows uses them to search for domain controllers and they are used by other protocols (XMMP, Kerberos, LDAP, etc.).

Instructions for setting up should always be provided by the provider of the service you are connecting to.

A Setup Example for Office 365:

Service Protocol Port Weight Priority TTL Name Target
_sip _tls 443 1 100 3600 @ sipdir.online.lync.com

The @ character next to the Name value means an empty entry, otherwise there may be a subdomain.

From the above entry, set the SRV record according to the key:

Name: service.protocol.name
TTL: TTL
Typ: SRV
Data: priority weight port target