SIP defines a mechanism in RFC 3263 “Locating SIP Servers” for determining the location of SIP servers as well as the transport protocol(s) supported by a server. RFC 3263 specifies the use of both DNS SRV (RFC 2782) and NAPTR (RFC 2915) records. Consider the example call flow below.In this example, before Proxy 1 can forward the INVITE to Proxy 2, it must first determine the IP address and supported transport protocols of Proxy 2. Proxy 1 accomplishes this by first performing a DNS NAPTR query for the domain specified by the request URI of the INVITE message. For instance if the INVITE is destined to [email protected], when the INVITE reaches Proxy 1, it would do a NAPTR lookup on the vocal.com domain. In this example the DNS server returns the following NAPTR records:
order pref flags service regexp replacement IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.vocal.com. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.vocal.com IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.vocal.com.
This result indicates that the SIP server responsible for the vocal.com domain supports TLS over TCP, TCP, and UDP in that order of preference. Proxy 1 then chooses the highest priority transport that it supports. In this example Proxy 1 supports TCP so it next does a DNS SRV lookup on _sip._tcp.vocal.com. This consequent lookup returns the following SRV record:
Priority Weight Port Target IN SRV 0 1 5060 server1.vocal.com IN SRV 0 2 5060 server2.vocal.com
Proxy 1 then perform a standard DNS A record lookup of the first target, server1.vocal.com, and attempts to forward the message to the IP address resolved by this lookup and port returned in the SRV record. If a SIP failure message is received, or if the transaction times out before any response is received, Proxy 1 then performs a DNS A record lookup on the second target, server2.vocal.com, and attempts to forward the message to the IP address resolved by this second lookup. If this attempt fails, the SIP transaction has failed and should be properly terminated.