When a SIP endpoint is ready to register with a service, it has the name of the service and the Address of Record (AoR) that it wants to register under. Both of these are constructed as SIP URIs. For example, my phone might register sip:Robert.Sparks@tekelec.com by sending a REGISTER request to sip:tekelec.com. It takes the domain name from that URI and uses it to start a series of DNS queries as specified in RFC 3263 : Locating SIP Servers.
The algorithms specified in that RFC allow an endpoint to learn what transport (UDP, TCP, TLS over TCP, SCTP) to use, and what IP address and port to send the message to. They also give the service provider tools to provide redundancy and load-leveling. Here’s a short overview of how it works:
The endpoint will first make a query for all Naming Authority Pointer (NAPTR) records for tekelec.com. These records allow service providers to advertise various services. The records that are returned might look like this:
The service field contains strings like “SIP+D2U” identifying the service being advertised – the full set of strings currently defined for SIP is:
SIP+D2T (SIP over TCP)
SIPS+D2T (SIP over TLS over TCP)
SIP+D2U (SIP over UDP)
SIP+D2S (SIP over SCTP)
SIPS+D2S (SIP over TLS over SCTP)
As new service strings are standardized, they will be registered with IANA.
The order and service fields allow the service provider to say things like “If you support it, you must use TCP” or “Try TCP first and if that fails, try UDP”. The numbers are processed from lowest to highest. Records with lower order values are inspected first. Once a record is found with a protocol the endpoint supports, it will only consider other records with that same order value. When multiple records appear with the same order value, they are considered in preference order.
If these records are returned, the service is saying “If you support TCP, use that. If it fails stop. Only try UDP if you don’t support TCP.”
tekelec.com. IN NAPTR 10 50 “s” “SIP+D2T” “” _sip._tcp.tekelec.com.
tekelec.com. IN NAPTR 20 50 “s” “SIP+D2U” “” _sip._udp.tekelec.com.
If the following records are returned, the service is saying “Try SCTP first if you support it. If you don’t or it fails, try TCP. If you don’t support that, or it fails, try UDP”:
tekelec.com. IN NAPTR 50 10 “s” “SIP+D2S” “” _sip._sctp.tekelec.com.
tekelec.com. IN NAPTR 50 20 “s” “SIP+D2T” “” _sip._tcp.tekelec.com.
tekelec.com. IN NAPTR 50 30 “s” “SIP+D2U” “” _sip._udp.tekelec.com.
Let’s proceed assuming those last three records were returned, and that the endpoint I’m using only supports TCP and UPD. In this case, the endpoint will use the second of those three records, learning that it should use TCP and it should take “_sip._tcp.tekelec.com” as input into the next step.
The endpoint now queries the DNS for all the SRV records matching “_sip._tcp.tekelec.com”. The SRV records returned will have this form:
The endpoint will process all records ordered by the priority field, from lowest to highest. If multiple records have the same priority, the endpoint will choose randomly from them, weighting the probability of selecting a particular record using the weight field. This gives the service provider a tool to realize a form of load distribution.
Assume the following records are returned:
_sip._tcp.tekelec.com. IN SRV 10 1 5060 crowned.tekelec.com.
_sip._tcp.tekelec.com. IN SRV 10 1 5065 crested.tekelec.com.
_sip._tcp.tekelec.com. IN SRV 10 2 6065 golden.tekelec.com.
The endpoint will randomly choose crowned.tekelec.com 1/4 of the time, crested.tekelec.com 1/4 of the time, and golden.tekelec.com 2/4 = 1/2 of the time. Lets assume the random selection chose crested.tekelec.com. The endpoint knows to use port 5065 when it sends its request.
Finally, the endpoint looks up A or AAAA (depending on whether it is using IPv4 or IPv6) records for crested.tekelec.com, yielding the IP address to send.
At this point the endpoint has the information it needs to send the request to the right server.
That example assumed that the endpoint was starting with a SIP URI. The RFC 3263 steps are the same whether the endpoint is preparing to send a REGISTER request or an INVITE request to start a call.
Sometimes, the endpoint starts with an E.164 formatted telephone number instead of a SIP URI. The ENUM specs define how to convert that telephone number into a URI. Once the endpoint has performed that conversion, it follows the same RFC 3263 algorithm discussed above starting with that URI to find the server to contact.