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
datatracker.ietf.org