2. Problems DNS is Needed to Solve
DNS is needed to help solve two aspects of the general call flow described in the Introduction. The first is for proxy 1 to discover the SIP server in domain B, in order to forward the call for joe@B. The second is for proxy 2 to identify a backup for proxy 1 in the event it fails after forwarding the request. For the first aspect, proxy 1 specifically needs to determine the IP address, port, and transport protocol for the server in domain B. The choice of transport protocol is particularly noteworthy. Unlike many other protocols, SIP can run over a variety of transport protocols, including TCP, UDP, and SCTP. SIP can also use TLS. Currently, use of TLS is defined for TCP only. Thus, clients need to be able to automatically determine which transport protocols are available. The proxy sending the request has a particular set of transport protocols it supports and a preference for using those transport protocols. Proxy 2 has its own set of transport protocols it supports, and relative preferences for those transport protocols. All proxies must implement both UDP and TCP, along with TLS over TCP, so that there is always an intersection of capabilities. Some form of DNS procedures are needed for proxy 1 to discover the available transport protocols for SIP services at domain B, and the relative preferences of those transport protocols. Proxy 1 intersects its list of supported transport protocols with those of proxy 2 and then chooses the protocol preferred by proxy 2. ............................ .............................. . . . . . +-------+ . . +-------+ . . | | . . | | . . | Proxy |------------- | Proxy | . . | 1 | . . | 2 | . . | | . . | | . . / +-------+ . . +-------+ \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . +-------+ . . +-------+ . . | | . . | | . . | | . . | | . . | UA 1 | . . | UA 2 | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . ............................ .............................. Figure 1: The SIP trapezoid It is important to note that DNS lookups can be used multiple times throughout the processing of a call. In general, an element that wishes to send a request (called a client) may need to perform DNS processing to determine the IP address, port, and transport protocol of a next hop element, 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 complete a transaction between a caller and called party is important. Typically, the time from when the caller initiates a call until the time the called party is alerted should be no more than a few seconds. Given that there can be multiple hops, each of which is doing DNS lookups in addition to other potentially time-intensive operations, the amount of time available for DNS lookups at each hop is limited. Scalability and high availability are important in SIP. SIP services scale up through clustering techniques. Typically, in a realistic version of the network in Figure 1, proxy 2 would 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. SIP assures high availability by having upstream elements detect failures. For example, assume that proxy 2 is implemented as a cluster of two proxies, proxy 2.1 and proxy 2.2. If proxy 1 sends a request to proxy 2.1 and the request fails, it retries the request by sending it to proxy 2.2. In many cases, 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 completes. Proxy 1 may 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, and the possibly long intervals between communications between a pair of domains, it is not generally possible for an element to maintain dynamic availability state for the proxies 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 that is available. The identity of the available server would ideally be cached for some amount of time in order to reduce call setup delays of subsequent calls. The client cannot query a failed server continuously to determine when it becomes available again, since this does not scale. Furthermore, the availability 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. The second aspect of the flow in the introduction for which DNS is needed, is for proxy 2 to identify a backup for proxy 1 that it can send the response to. This problem is more realistic in SIP than it is in other transactional protocols. The reason is that some SIP responses 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.