Session Initiation Protocol (SIP): Locating SIP Servers
RFC 3263
Document | Type |
RFC - Proposed Standard
(July 2002; No errata)
Obsoletes RFC 2543
Was draft-ietf-sip-srv (sip WG)
|
|
---|---|---|---|
Authors | Henning Schulzrinne , Jonathan Rosenberg | ||
Last updated | 2015-12-07 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3263 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
IESG note |
RFCs 3261-3265 Responsible: Finished |
||
Send notices to | sipcore@ietf.org, dispatch@ietf.org |
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 formShow full document text