📄 rfc3263.txt
字号:
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
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 [Page 2]
RFC 3263 SIP: Locating SIP Servers June 2002
............................ ..............................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | 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
Rosenberg & Schulzrinne Standards Track [Page 3]
RFC 3263 SIP: Locating SIP Servers June 2002
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.
Rosenberg & Schulzrinne Standards Track [Page 4]
RFC 3263 SIP: Locating SIP Servers June 2002
3 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and
indicate requirement levels for compliant SIP implementations.
4 Client Usage
Usage of DNS differs for clients and for servers. This section
discusses client usage. We assume that the client is stateful
(either a User Agent Client (UAC) or a stateful proxy). Stateless
proxies are discussed in Section 4.4.
The procedures here are invoked when a client needs to send a request
to a resource identified by a SIP or SIPS (secure SIP) URI. This URI
can identify the desired resource to which the request is targeted
(in which case, the URI is found in the Request-URI), or it can
identify an intermediate hop towards that resource (in which case,
the URI is found in the Route header). The procedures defined here
in no way affect this URI (i.e., the URI is not rewritten with the
result of the DNS lookup), they only result in an IP address, port
and transport protocol where the request can be sent. RFC 3261 [1]
provides guidelines on determining which URI needs to be resolved in
DNS to determine the host that the request needs to be sent to. In
some cases, also documented in [1], the request can be sent to a
specific intermediate proxy not identified by a SIP URI, but rather,
by a hostname or numeric IP address. In that case, a temporary URI,
used for purposes of this specification, is constructed. That URI is
of the form sip:<proxy>, where <proxy> is the FQDN or numeric IP
address of the next-hop proxy. As a result, in all cases, the
problem boils down to resolution of a SIP or SIPS URI in DNS to
determine the IP address, port, and transport of the host to which
the request is to be sent.
The procedures here MUST be done exactly once per transaction, where
transaction is as defined in [1]. That is, once a SIP server has
successfully been contacted (success is defined below), all
retransmissions of the SIP request and the ACK for non-2xx SIP
responses to INVITE MUST be sent to the same host. Furthermore, a
CANCEL for a particular SIP request MUST be sent to the same SIP
server that the SIP request was delivered to.
Because the ACK request for 2xx responses to INVITE constitutes a
different transaction, there is no requirement that it be delivered
to the same server that received the original request (indeed, if
that server did not record-route, it will not get the ACK).
Rosenberg & Schulzrinne Standards Track [Page 5]
RFC 3263 SIP: Locating SIP Servers June 2002
We define TARGET as the value of the maddr parameter of the URI, if
present, otherwise, the host value of the hostport component of the
URI. It identifies the domain to be contacted. A description of the
SIP and SIPS URIs and a definition of these parameters can be found
in [1].
We determine the transport protocol, port and IP address of a
suitable instance of TARGET in Sections 4.1 and 4.2.
4.1 Selecting a Transport Protocol
First, the client selects a transport protocol.
If the URI specifies a transport protocol in the transport parameter,
that transport protocol SHOULD be used.
Otherwise, if no transport protocol is specified, but the TARGET is a
numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP
for a SIPS URI. Similarly, if no transport protocol is specified,
and the TARGET is not numeric, but an explicit port is provided, the
client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI. This is
because UDP is the only mandatory transport in RFC 2543 [6], and thus
the only one guaranteed to be interoperable for a SIP URI. It was
also specified as the default transport in RFC 2543 when no transport
was present in the SIP URI. However, another transport, such as TCP,
MAY be used if the guidelines of SIP mandate it for this particular
request. That is the case, for example, for requests that exceed the
path MTU.
Otherwise, if no transport protocol or port is specified, and the
target is not a numeric IP address, the client SHOULD perform a NAPTR
query for the domain in the URI. The services relevant for the task
of transport protocol selection are those with NAPTR service fields
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -