Session Initiation Protocol (SIP): Locating SIP Servers
RFC 3263

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

Network Working Group                                       J. Rosenberg
Request for Comments: 3263                                   dynamicsoft
Obsoletes: 2543                                           H. Schulzrinne
Category: Standards Track                                    Columbia U.
                                                               June 2002

        Session Initiation Protocol (SIP): Locating SIP Servers

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   The Session Initiation Protocol (SIP) uses DNS procedures to allow a
   client to resolve a SIP Uniform Resource Identifier (URI) into the IP
   address, port, and transport protocol of the next hop to contact.  It
   also uses DNS to allow a server to send a response to a backup client
   if the primary client has failed.  This document describes those DNS
   procedures in detail.

Table of Contents

   1          Introduction ........................................    2
   2          Problems DNS is Needed to Solve .....................    2
   3          Terminology .........................................    5
   4          Client Usage ........................................    5
   4.1        Selecting a Transport Protocol ......................    6
   4.2        Determining Port and IP Address .....................    8
   4.3        Details of RFC 2782 Process .........................    9
   4.4        Consideration for Stateless Proxies .................   10
   5          Server Usage ........................................   11
   6          Constructing SIP URIs ...............................   12
   7          Security Considerations .............................   12
   8          The Transport Determination Application .............   13
   9          IANA Considerations .................................   14
   10         Acknowledgements ....................................   14
   11         Normative References ................................   15
   12         Informative References ..............................   15

Rosenberg & Schulzrinne     Standards Track                     [Page 1]
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