RFC3263 Session Initiation Protocol (SIP): Locating SIP Servers This document describes DNS procedure used in SIP, including: A client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. A server to send a response to a backup client if the primary client has failed. 1 Client Usage 1.1 Stateful (either a User Agent Client (UAC) or a stateful proxy) The procedures here are invoked when a client needs to send a request to a resource identified by a SIP or SIPS (secure SIP) URI. They only result in an IP address, port and transport protocol where the request can be sent. The procedures here MUST be done exactly once per transaction. That is, once a SIP server has successfully been contacted (success is defined below), all retransmissions of the SIP request and the ACK for non-2xx SIP responses to INVITE MUST be sent to the same host. Furthermore, a CANCEL for a particular SIP request MUST be sent to the same SIP server that the SIP request was delivered to. The ACK for 2xx responses is not required to be delivered to the same server that received the original request (indeed, if that server did not record-route, it will not get the ACK). 1.1.1 Selecting a Transport Protocol |-------------------------------------------------------------------| | Defined | NOT Defined in URI | | in URI | | |---------|---------------------------------------------------------| | | Numeric IP | Explicit | URI | NAPTR | SRV | Transport | | | Address | Port | Type | | | Proctocol | | |------------|----------|------|--------|-----|-----------| | | | | SIP | | | UDP | | | YES | |------|--------|-----|-----------| | | | | SIPS | | | TCP | | |------------|----------|------|--------|-----|-----------| | | | | SIP | | | UDP | | | | YES |------|--------|-----|-----------| | SHOULD | | | SIPS | | | TCP | | Be Used | |----------|------|--------|-----|-----------| | | | | |SIP+D2U | | UDP | | | | | |--------|-----|-----------| | | | | |SIP+D2T | | TCP | | | | | |--------|-----|-----------| | | | | SIP |SIP+D2S | | SCTP | | | | | |--------|-----|-----------| | | | | | | OK | (SRV) | | | NO | | | FAIL |-----|-----------| | | | | | | FAIL| UDP | | | | NO |------|--------|-----|-----------| | | | | |SIPS+D2U| | ERR | | | | | |--------|-----|-----------| | | | | |SIPS+D2T| | TLS | | | | | |--------|-----|-----------| | | | | SIPS |SIPS+D2S| | SCTP | | | | | |--------|-----|-----------| | | | | | | OK | (SRV) | | | | | | FAIL |-----|-----------| | | | | | | FAIL| TCP | |-------------------------------------------------------------------| Table 1: Determining Transport Protocol on Client While multiple NAPTR records, additional rules as follow: Resolving a SIPS URI MUST discard any services that do not contain "SIPS" as the protocol in the service field. A client resolving a SIP URI SHOULD retain records with "SIPS" as the protocol, if the client supports TLS. MUST discard any service fields that identify a resolution service whose value is not "D2X". The NAPTR processing as described in RFC 2915 will result in the discovery of the most preferred transport protocol of the server that is supported by the client, as well as an SRV record for the server. It will also allow the client to discover if TLS is available and its preference for its usage. If a SIP proxy, redirect server, or registrar is to be contacted through the lookup of NAPTR records, there MUST be at least three records: one with a "SIP+D2T" service field one with a "SIP+D2U" service field one with a "SIPS+D2T" service field The records with SIPS as the protocol in the service field SHOULD be preferred (i.e., have a lower value of the order field) above records with SIP as the protocol in the service field. A record with a "SIPS+D2U" service field SHOULD NOT be placed into the DNS, since it is not possible to use TLS over UDP. It is not necessary for the domain suffixes in the NAPTR replacement field to match the domain of the original query (i.e., example.com above). However, for backwards compatibility with RFC 2543, a domain MUST maintain SRV records for the domain of the original query, even if the NAPTR record is in a different domain. As an example, even though the SRV record for TCP is _sip._tcp.school.edu, there MUST also be an SRV record at _sip._tcp.example.com. RFC 2543 will look up the SRV records for the domain directly. If these do not exist because the NAPTR replacement points to a different domain, the client will fail. For NAPTR records with SIPS protocol fields, (if the server is using a site certificate), the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior or the result of an attack. If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each. Queries are done using the service identifier "_sip" for SIP URIs and "_sips" for SIPS URIs. A particular transport is supported if the query is successful. The client MAY use any transport protocol it desires which is supported by the server. This is a change from RFC 2543. It specified that a client would lookup SRV records for all transports it supported, and merge the priority values across those records. Then, it would choose the most preferred record. Another transport protocol, such as TCP, MAY be used if the guidelines of SIP mandate it for this particular request. That is the case, for example, for requests that exceed the path MTU. 1.1.2 Determining Port and IP Address |----------------------------------------------------------| | Numeric IP | Explicit | NAPTR | SRV | Ip & Port | | Address | Port | | | | |------------|----------|-------|------|-------------------| | YES | YES | | | use in URI | |------------|----------|-------|------|-------------------| | YES | NO | | | Ip use in URI | | | | | | Port use default | |------------|----------|-------|------|-------------------| | NO | YES | | | Ip use A / AAAA | | | | | | Port use in URI | |------------|----------|-------|------|-------------------| | | | NOT | NOT | result of SRV on | | | | DONE | DONE | transport in uri | | | |-------|------|-------------------| | NO | NO | DONE | NOT | SRV on the record | | | | | DONE | from NAPTR | | | |-------|------|-------------------| | | | FAIL | DONE | result of SRV | | | |-------|------|-------------------| | | | FAIL | FAIL | Ip use A / AAAA | | | | | | Port use default | |----------------------------------------------------------| Table 2: Determining Port and IP Address on Client The client performs an SRV query for specific transport in uri, using the service identifier "_sips" for SIPS URIs. For a SIP URI, if the client wishes to use TLS, it also uses the service identifier "_sips" for that specific transport, otherwise, it uses "_sip". 1.1.3 Details of RFC 2782 Process RFC 2782 spells out the details of how a set of SRV records are sorted and then tried. However, it only states that the client should "try to connect to the (protocol, address, service)" without giving any details on what happens in the event of failure. Those details are described here for SIP. For SIP requests, failure occurs if the transaction layer reports a 503 error response or a transport failure of some sort (generally, due to fatal ICMP errors in UDP or connection failures in TCP). Failure also occurs if the transaction layer times out without ever having received any response, provisional or final (i.e., timer B or timer F in RFC 3261 [1] fires). If a failure occurs, the client SHOULD create a new request, which is identical to the previous, but has a different value of the Via branch ID than the previous (and therefore constitutes a new SIP transaction). That request is sent to the next element in the list as specified by RFC 2782. 1.2 Stateless Proxies The key for stataless proxies is when a server is contacted successfully, all retransmissions of the request for the transaction, as well as ACK for a non-2xx final response, and CANCEL requests for that transaction, MUST go to the same server. The requirement is not difficult to meet in the simple case where there were no failures when attempting to contact a server. Whenever the stateless proxy receives the request, it performs the appropriate DNS queries as described above. However, the procedures of RFC 2782 are not guaranteed to be deterministic. This is because records that contain the same priority have no specified order. The stateless proxy MUST define a deterministic order to the records in that case, using any algorithm at its disposal. One suggestion is to alphabetize them, or, more generally, sort them by ASCII-compatible encoding. To make processing easier for stateless proxies, it is RECOMMENDED that domain administrators make the weights of SRV records with equal priority different (for example, using weights of 1000 and 1001 if two servers are equivalent, rather than assigning both a weight of 1000), and similarly for NAPTR records. If the first server is contacted successfully, the proxy can remain stateless. However, if the first server is not contacted successfully, and a subsequent server is, the proxy cannot remain stateless for this transaction. If it were stateless, a retransmission could very well go to a different server if the failed one recovers between retransmissions. As such, whenever a proxy does not successfully contact the first server, it SHOULD act as a stateful proxy. Unfortunately, it is still possible for a stateless proxy to deliver retransmissions to different servers, even if it follows the recommendations above. This can happen if the DNS TTLs expire in the middle of a transaction, and the entries had changed. This is unavoidable. Network implementors should be aware of this limitation, and not use stateless proxies that access DNS if this error is deemed critical. 2 Server Usage For unicast UDP requests, the response is sent back to the source IP address where the request came from, using the port contained in the Via header. However, it is important to provide failover support when the client element fails between sending the request and receiving the response. For reliable transport protocols, the response is sent over the connection the request arrived on. |------------------------------------------------------------------| | Numeric IP | Domain | port | Transfer | IP, Port, Protocol | | Address | Name | | Protocol | for Transport | |------------|--------|------|----------|--------------------------| | YES | | YES | YES | use from Via | |------------|--------|------|----------|--------------------------| | | | | | use from Via | | YES | | YES | NO | default transport | | | | | | protocol | |------------|--------|------|----------|--------------------------| | | YES | YES | YES | use from Via | | | | | | IP from A / AAAA | |------------|--------|------|----------|--------------------------| | | YES | NO | TLS | IP & Port from SRV | | | | | | with identifier "_sips" | |------------|--------|------|----------|--------------------------| | | YES | NO | non-TLS | IP & Port from SRV | | | | | | with identifier "_sip" | |------------------------------------------------------------------| Table 3: Determining IP, Port, Protocol on Server 3 Constructing SIP URIs If the URIs are constructed with an IP address, then should the element fail, there is no way to route the request or response through a backup. SRV provides a way to fix this. Instead of using an IP address, a domain name that resolves to an SRV record can be used. 4 The Transport Determination Application This section more formally defines the NAPTR usage of this specification, using the Dynamic Delegation Discovery System (DDDS) framework as a guide [7]. DDDS represents the evolution of the NAPTR resource record. DDDS defines applications, which can make use of the NAPTR record for specific resolution services. This application is called the Transport Determination Application, and its goal is to map an incoming SIP or SIPS URI to a set of SRV records for the various servers that can handle the URI. The following is the information that DDDS requests an application to provide: Application Unique String: The Application Unique String (AUS) is the input to the resolution service. For this application, it is the URI to resolve. First Well Known Rule: The first well known rule extracts a key from the AUS. For this application, the first well known rule extracts the host portion of the SIP or SIPS URI. Valid Databases: The key resulting from the first well known rule is looked up in a single database, the DNS [8]. Expected Output: The result of the application is an SRV record for the server to contact.