Internet Engineering Task Force SIP WG Internet Draft
Schulzrinne/Rosenberg draft-ietf-sip-srv-02.txt Columbia U./dynamicsoft MarchJ.Rosenberg,H.Schulzrinne draft-ietf-sip-srv-03.txt dynamicsoft,Columbia U. December 24, 2001 Expires: June 2001May 2002 SIP: Session Initiation Protocol --Locating SIP Servers STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document describes howThe Session Initiation Protocol (SIP) makes use of DNS procedures to allow a SIPclient locatesto resolve a SIP URI into the IP address, port, and transport of the next hop to contact. It also uses DNS to allow a server based onto send a response to a backup client in the Request-URI orevent of a preconfigured outbound proxy server.failure of the primary client. This document updates the process describeddescribes those DNS pro- cedures in RFC 2543.detail. 1 Introduction This document updates Sections 1.3 and 1.4.2 and supersedes Appendix D of RFC 2543 . Inter alia, it definesThe Session Initiation Protocol (SIP)  is a client-server protocol used for the term outbound proxyinitiation and replaces referencesmanagement of communications sessions between users. SIP end systems are called user agents, and intermedi- ate elements are known as proxy servers. A typical SIP configuration, referred to as the obsoleted RFC 2052 with current references to RFC 2782. 1.1 TerminologySIP "trapezoid" is shown in Figure 1. In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" arediagram, a caller, UA1 wishes to be interpreted as described in RFC 2119  and indicate requirement levels for compliant SIP implementations. 1.2 Definitions Outbound proxy: Acall joe@B. To do so, it communi- cates with proxy that is located near1 in its domain (domain A). Proxy 1 forwards the originator of requests. It receives all outgoing requests from a particular UAC, including those requests whose Request-URLs identify a host other thanrequest to the outbound proxy. The outboundproxy sends these requests, after any local processing, tofor the address indicated indomain of the Request-URI. (All othercalled party (domain B), which is proxy servers are simply referred as proxies, not inbound proxies.)2. Proxy 2 Locating a SIP Server When a client wishesforwards the call to send a request,the client either sends itcalled party, UA 2. As part of this call flow, proxy 1 needs to determine a locally configuredSIP server for domain B. To do this, proxy server,1 makes use of DNS procedures, using both the so-called outbound proxy , independentSRV  and NAPTR  records. This document describes the specific problems that SIP uses DNS to help solve, and provides a solution. 2 Problems DNS is Needed to Solve DNS is needed to help solve several aspects of the Request-URI, or sendsgeneral call flow described in the Introduction. First off, proxy 1 needs to discover the SIP server in domain B, in order to forward the call for joe@B. Specifically, it needs to deter- mine the IP address andaddress, port corresponding toand transport for the Request-URI. The outbound proxyserver in domain B. Transport is particularly noteworthy. Unlike other protocols, SIP can be configured by any mechanism,run over a variety of transports, including DHCP TCP, UDP, TLS/TCP and can be specified either asSCTP. Therefore, discovery of transports for a particular domain is an important part of the processing. The proxy sending the request has a particular set of parameters such as network address or host name, protocol porttransports it supports (all proxies must implement both TCP and UDP) and transport protocol, or asa preference for using those tran- sports. Proxy 2 has its own set of transports it supports (the minimal overlap is UDP and TCP in this case), and relative prefer- ences for those transports. Some form of DNS procedures are needed for proxy 1 to discover the available transports for SIP URI. Ifservices at domain B, and the Request-URI is used,relative preferences of those transports. This information can be merged with the client needssupported transports and prefer- ences at proxy 1, resulting in a selection of a transport. It is important to note that DNS processing can be used multiple times throughout processing of a call. In general, an element that wishes to send a request (generally called a client) may need to per- form DNS processing to determine the protocol, port andIP addressaddress, port, and transport of a next hop element, generally called a server (it can be a proxy or a user agent). Such processing could, in principle, occur at every hop between elements. Since SIP is used for the establishment of interactive communications services, the time it takes to which to sendcomplete a transaction between a caller and called party is important. Typically, the request. A client SHOULD followtotal delay between when a user initiates the call, and when they get an indica- tion that the steps belowcalled party is being alerted to obtain this information. Clients MUST re-runthe above selection algorithm, re-drawing any random numbers involved, once per transaction rathercall, needs to be ............................ .............................. . . . . . +-------+ . . +-------+ . . | | . . | | . . | Proxy |------------- | Proxy | . . | 1 | . . | 2 | . . | | . . | | . . / +-------+ . . +-------+ \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . +-------+ . . +-------+ . . | | . . | | . . | | . . | | . . | UA 1 | . . | UA 2 | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . ............................ .............................. Figure 1: The SIP trapezoid less than for each request, i.e., requests within the same transaction MUSTa few seconds. Given that there can be sentmultiple hops, each of which is doing DNS processing in addition to other potentially time-intensive operations, the same network address. Thus, the same address is usedamount of time available for the request, any retransmissions, any associated CANCEL requestsDNS pro- cessing at each hop is limited. Scalability and ACK requests for non-2xx responses. However, ACKs for 2xx responses use another iterationhigh availability are important in SIP. SIP services scale up through clustering techniques. In a more realistic version of the selection algorithm. (Indeed,network in many cases, they may have different request URIs.) A statelessFigure 1, proxy can accomplish this,2 would typically be a cluster of homogeneously configured proxies. DNS needs to provide the ability for domain B to configure a set of servers, along with prioritization and weights in order to provide a crude level of capacity based load balancing. High availability is accomplished in SIP through detection of failures by upstream elements. For example, proxy 1 would send a request to proxy 2.1 (one of the proxies in the "cluster" proxy 2). This request would fail, and that would be detected by usingproxy 1. Proxy 1 would then try another of the proxies, proxy 2.2. In many cases, such as the one above, proxy 1 will not know which domains it will ultimately communicate with. That information would be known when a user actually makes a call to another user in that domain. Proxy 1 may never communicate with that domain again after the call com- pletes. Proxy 1 could communicate with thousands of different domains within a few minutes, and proxy 2 could receive requests from thousands of different domains within a few minutes. Because of this "many-to-many" relationship, it is not generally possible for an ele- ment to perpetually maintain dynamic availability state for the prox- ies it will communicate with. When a proxy gets its first call with a particular domain, it will try the servers in that domain in some order until it finds one thats available. The identity of the avail- able server would ideally be cached for some amount of time in order to reduce call setup delays of subsequent calls. However, the client cannot actively "ping" the failed servers to determine when they come back alive, because of scalability concerns. Furthermore, the availa- bility state must eventually be flushed in order to redistribute load to recovered elements when they come back online. It is possible for elements to fail in the middle of a transaction. For example, after proxy 2 forwards the request to UA 2, proxy 1 fails. UA 2 sends its response to proxy 2, which tries to forward it to proxy 1, which is no longer available. Ideally, we would like proxy 2 to use DNS procedures to identify a backup server for proxy 1 that it can use to forward the response. This problem is more realis- tic in SIP than it is in other transactional protocols. The reason is that a SIP response can take a *long* time to be generated, because a human user frequently needs to be consulted in order to generate that response. As such, it is not uncommon for tens of seconds to elapse between a call request and its acceptance. 3 Client Usage Usage of DNS differs for clients and for servers. This section discusses client usage. The assumption is that the client is stateful (either a UAC or a stateful proxy). Considerations for stateless proxies are discussed in Section 3.4. The procedures here are invoked when a client needs to send a request to a server for which it does not already know an explicit IP address, port, and transport. This occurs when an element wishes to send a request to a server identified by a SIP URI, or when an ele- ment wishes to send a request to a specific configured server, independent of the SIP URI, but the configured server is identified by a domain name instead of a numeric IP address. The procedures here MUST only be done once per transaction. That is, once a server has successfully been contacted (success is defined below), all retransmissions of the request and the ACK for non-2xx responses MUST be sent to the same server. Furthermore, a CANCEL for a particular request MUST be sent to the same server that the request was delivered to. Note that, because the ACK request for 2xx responses constitutes a different transaction, there is no requirement that it be delivered to the same server that received the original request (indeed, if that server did not record-route, it will most definitely not get the ACK). If the request is being delivered to an outbound proxy, a temporary URI, used for purposes of this specification, is constructed. That URI is of the form sip:<proxy>, where <proxy> is the domain of the outbound proxy. The first step is to identify the TARGET. The TARGET is set to the value of the maddr parameter of the URI, if present, otherwise, the host value of the hostport construction. It represents the domain to be contacted. 3.1 Selecting a Transport Next, a transport is selected. If the URI specifies a transport, that transport MUST be used. Otherwise, if no transport is specified, but the TARGET is a numeric IP address, the client SHOULD use UDP. Otherwise, if no transport is specified, and the target is not a numeric IP address, the client SHOULD perform a NAPTR query. This query is for the service "SIP+D2T", which provides a mapping from a domain to a transport for contacting that domain. The transport is of the form of an SRV record, using the "S" NAPTR flag. The resource record will contain a replacement value (not a regular expression), which is the SRV record for a particular transport. If the server supports multiple transports, there will be multiple NAPTR records, each with a different order value. The client MUST discard any records that contain an SRV value with a transport not supported by the client, but otherwise follow the processing rules of . The result is that the most preferred transport of the server that is supported by the client will get used. As an example, consider foo.com. A client wishes to contact a SIP server in foo.com. It performs a NAPTR query for that domain, and the following records are returned: ;; order pref flags service regexp replacement IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.foo.com IN NAPTR 100 50 "s" "SIP+D2T" "" _sip._udp.foo.com IN NAPTR 110 50 "s" "SIP+D2T" "" _sip._tls.foo.com This indicates that the server supports TCP, UDP, and TLS, in that order of preference. If the client supports UDP and TLS, UDP will be used, based on an SRV lookup of _sip._udp.foo.com. Somehow this doesn't seem right, since the client needs to look at the replacement values to discard entries. Perhaps the query should instead be done for sip.<domain>, and the service field is "TCP+D2T" or "UDP+D2T"? It is STRONGLY RECOMMENDED that the domain suffixes in the replace- ment field (i.e., foo.com above) match the domain of the original query. Without that, backwards compatibility between RFC 2543 and this specification will not be possible. THis is because RFC 2543 clients will go directly to SRV records using the domain suffixes. If these are non- existent, because the NAPTR replacement used a different suffix, communication will not take place. In the event that no NAPTR records are found, the client constructs SRV records for those transports it supports, and does a query for each. Queries are done using the service identifier "_sip". If the query is successful, it means that the particular transport is sup- ported. The client MAY use any transport it desires which is sup- ported by the server. This is a change from RFC 2543, which used to merge the priority values across different SRV records. 3.2 Determining port and IP Once the transport has been determined, the next step is to determine the IP address and port. If TARGET is a numeric IP address, use that address. If the URI also contains a port, use that port. If no port is specified, use the default port for the particular transport. If the TARGET was not a numeric IP address, but a port is present in the URI, first check the cache to determine if a server has been pre- viously contacted successfully for that TARGET and port. If one has been, use that server. Otherwise, perform an A or AAAA record lookup of the domain name. The result will be a list of IP address, each of which can be contacted at the specific port from the URI and tran- sport determined previously. Processing then proceeds as described in Section 3.3. There is a weird case where, where the URI had a domain name and a port. SRV records will potentially be used to determine the transport, based on the algorithms above, but A records used for the actual lookup. That seems odd. If the TARGET was not a numeric IP address, and no port was present in the URI, first check the cache to see if a server had been previ- ously contacted successfully for that TARGET. If one had been, use that. Otherwise, perform an SRV query using the service identifier "_sip" and the transport as determined from Section 3.1, as specified in RFC 2782 . The procedures of RFC 2782, as described in the Sec- tion titled "Usage rules" are followed, augmented by the additional procedures of Section 3.3. This is a change. Previously, if the port was explicit, but with a value of 5060, SRV records were used. Now, A records will be used. A result of this is that the URL comparison rules need to change to reflect that sip:user@foo and sip:user@foo:5060 are NOT equivalent any longer. I think this should not cause any serious interoperability issues, but further consideration is needed. 3.3 Details of 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, in the case of SIP, are described here. For SIP requests, failure occurs if the modulo N oftransaction layer reports a 503 error response or a hashtransport failure of some sort (generally, due to ICMP errors or TCP connection failures). Failure also occurs if the Call-ID valuetransaction layer times out without ever having received ANY response, provisional or some other combination of transaction-identifying headers asfinal (i.e., timer B or timer F fires). If a failure occurs, the uniform random number described inclient SHOULD create a new request, which is identical to the weighting algorithmprevious, but has a different value of RFC 2782. Here, Nthe Via branch ID than the previous (and therefore constitutes a new SIP transaction). That request is sent to the sum of weights withinnext element in the priority class.list as specified by rfc2782. A client SHOULD be ableserver has been contacted "successfully" if a request sent to interpret explicit network notifications (such as ICMP messages) which indicatethat aserver is not reachable, rather than relying solely on timeouts. (For socket-based programs: For TCP, connect() returns ECONNREFUSED ifgenerates any kind of response, provisional or final. A map- ping of the client could not connecttuple (TARGET, input TRANSPORT, input PORT) to a specific server at(IP address, transport, port) that address. For UDP, the socket needs towas contacted successfully SHOULD be boundcached for a duration equal to the destination address using connect() rather than sendto() or similar soTTL of the A record for that a second write() or send() fails with ECONNREFUSED if there is noserver listening) Ifitself. Note, in the above tuple, input TRANSPORT and input PORT refer to the transport and port values from the URI itself, if present. If a client findsattempts to contact the server listed in the cache, but the request fails, the server MUST be removed from the cache, and the entire DNS processing must restart by following the procedures in Section 3.1 again. 3.4 Consideration for Stateless Proxies The process of the previous sections is not reachable athighly stateful. When a particular address, it SHOULD behave as if it had receivedserver is contacted successfully, all requests for the transaction (plus a 400-class error response toCANCEL for that request. The client triestransaction) MUST go to find one or more addresses forthe SIPsame server. The identity of the successfully contacted server by querying DNS. Ifis a step elicits no addresses,form of transac- tion state. This presents a challenge for stateless proxies, which still need to meet the client continuesrequiretment for sending all requests in the transaction to the next step. However if a step elicits one or more addresses, butsame server. The requirement is not difficult to meet in the simple case where there were no SIP server at any of those addresses responds, thenfailures when attempting to contact a server. Whenever the stateless proxy receives the client concludesrequest, it performs the server is downappropriate DNS queries as described above. Unfortunately, the procedures of RFC 2782 and doesRFC 2915 are not continue onguaranteed to the next step. If the clientbe deterministic. This is configured withbecause records that contain the address of an outbound proxy,same priority and weight (in the parameterscase of the outbound proxy, including transport protocolSRV) or order and port, becomepreference (in the destination used below. If there iscase of NAPTR) have no outbound proxy, the destination is the Request-URI.specified order. The destination address isstateless proxy MUST define a deterministic order to the maddr parameter ifrecords in that case, using any algorithm at its dispo- sal. One suggestion is to alphabetize them, for example. To make life easier for stateless proxies, it exists and the host element if not. The transport protocolis RECOMMENDED that domain adminis- trators make the transport parameter. The service identifier for DNSweights of SRV records  is "_sip". 1. If the destination address is a numeric IP address, the client contacts the server at the given addresswith equal priority different (for example, using weights of 1000 and the port number specified in the SIP-URI or,1001 if not specified, the default port (5060). If the destination specifiestwo servers are equivalent, rather than assigning both a protocol, the client contacts the server using that protocol.weight of 1000), and simi- larly for NAPTR records. If no protocol is specified,the clientfirst tries UDP. If attempt fails, orserver is contacted success- fully, things are fine. However, if the client doesfirst server is not support UDP but supports other protocols, it tries those protocols in some implementation-defined order. The client then skips the remaining steps. 2. If the destination specifies no port number or port number 5060,contacted successfully, and a subsequent server is, the transport protocol determinesproxy cannot remain stateless for this transaction. This is because a retransmission could very well go to a different server if the use offailed one of the following three rules: - If the destinationrecovers between retransmissions. As such, whenever a proxy does not specifysuccess- fully contact the first server, it SHOULD act as a transport protocol, DNS SRV records are retrieved accordingstateful proxy. 4 Server Usage RFC 2543bis defines procedures for sending responses from a server back to the client. Typically, for unicast requests, the response is sent back to RFC 2782 . The results ofthe query or queries are merged and ordered based on priority, keeping only records with transport protocols thatsource IP address where the client supports. Then,request came from, using the searching technique outlinedport contained in RFC 2782 the Via header. However, it is usedimportant to select servers in order. Server selection across requests is independent of previous choices, except as noted above for stateless proxies. Message length or otherprovide failover support when the client element fails between send- ing the request properties do not influenceand receiving the server selection.response. The procedures here are invoked when a server sends a response to the client attemptsand that response fails. "Fails" is defined here as any response which causes an ICMP error message to contact each server inbe returned, or when the order listed, attransport connection the port number specifiedrequest came in on closes before the SRV record. If none of the serversresponse can be contacted,sent. In these cases, the client gives up. If there are no SRV records (with any transport protocol), DNS address records are used, as described below. -server examines the value of the sent-by con- struction in the topmost Via header. If it contains a numeric IP address, the server attempts to send the response to that address, using the transport protocol is specifiedfrom the Via header, and this protocol is supported bythe client,port from sent-by, if present, else the procedure indefault for that transport. If, however, the paragraph above is used, limited to DNS resourcesent-by field contained a domain name and a port number, the server queries for A records with that name. It tries to send the transport protocol specified inresponse to each element on the SIP-URI. - Ifresulting list of IP addresses, using the port from the Via, and the transport protocol specified is not supported byfrom the client,Via. As in the client gives up. If there are no SRV records,processing, the next step applies. 3. Ifentry in the destination specifies a port number other than 5060 orlist is tred if there are no SRV records, the client queriesthe DNS server for address records for the destination address. Address records include A RR's, AAAA RR's, or other similar records, chosen according toone before it results in a failure. If, however, the client's network protocol capabilities. Ifsent-by field contained a domain name and no port, the DNSserver returns no address records,queries for SRV records using the client gives up. If there are address records,service identifier "_sip" and the same rulestransport from the topmost Via header. The resulting list is sorted as described in step 2 apply. Clients MUST NOT cache query results except according, and the response is sent to the rulestopmost element on the new list described there. If that results in RFC 1035 . 3a failure, the next entry on the list is tried. 5 Security Considerations The authors do not believe that this specification introduces any additional security considerationsissues beyond those already described in RFC 2543  apply. 4 Authors'2782 and RFC 2915. 6 Registration of NATPR D2T Resolution Service Name: Domain Name to Transport * Mnemonic: D2T * Number of Operands: 1 * Type of Each Operand: Each operand is a domain * Format of Each Operand: Each operand is a domain name in standard format * Algorithm: Opaque * Output: One or more SRV record keys * Error Conditions: o No overlap in transport between client and server * Security Considerations: 7 Author's Addresses Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA electronic mail: email@example.comJonathan Rosenberg dynamicsoft 72 Eagle Rock AveAvenue First Floor East Hanover, NJ 07936 USA electronic mail:email: firstname.lastname@example.org 58 Bibliography  M. Handley, H. Schulzrinne, E. Schooler, andJ. Rosenberg, H. Schulzrinne, et al. , "SIP: sessionSession initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999.  S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997.  G. Nair and H. Schulzrinne, "DHCP option for SIP servers,"Internet Draft, Internet Engineering Task Force, Apr. 2000.Oct. 2001. Work in progress.  A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)," Request for Comments 2782, Internet Engineering Task Force, Feb. 2000.  P. V. Mockapetris, "Domain names - implementation M. Mealling and specification,"R. Daniel, "The naming authority pointer (NAPTR) DNS resource record," Request for Comments 1035,2915, Internet Engineering Task Force, Nov. 1987. Full Copyright Statement Copyright (c) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Sept. 2000.