RFC 3263 (rfc3263) - Page 2 of 17

Session Initiation Protocol (SIP): Locating SIP Servers

RFC 3263               SIP: Locating SIP Servers               June 2002


   13         Authors' Addresses ..................................   16
   14         Full Copyright Statement ............................   17

1 Introduction

   The Session Initiation Protocol (SIP) (RFC 3261 [1]) is a client-
   server protocol used for the initiation and management of
   communications sessions between users.  SIP end systems are called
   user agents, and intermediate elements are known as proxy servers.  A
   typical SIP configuration, referred to as the SIP "trapezoid", is
   shown in Figure 1.  In this diagram, a caller in domain A (UA1)
   wishes to call Joe in domain B (joe@B).  To do so, it communicates
   with proxy 1 in its domain (domain A).  Proxy 1 forwards the request
   to the proxy for the domain of the called party (domain B), which is
   proxy 2.  Proxy 2 forwards the call to the called party, UA 2.

   As part of this call flow, proxy 1 needs to determine a SIP server
   for domain B.  To do this, proxy 1 makes use of DNS procedures, using
   both SRV [2] and NAPTR [3] 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 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.



Rosenberg & Schulzrinne     Standards Track