As per Relevance of the word transport, we have this rfc below:
Network Working Group J.
Request for Comments: 3263
Obsoletes: 2543 H.
Category: Standards Track Columbia U
June 2002
Session Initiation Protocol (SIP): Locating SIP
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
The Session Initiation Protocol (SIP) uses DNS procedures to allow
client to resolve a SIP Uniform Resource Identifier (URI) into the
address, port, and transport protocol of the next hop to contact.
also uses DNS to allow a server to send a response to a backup
if the primary client has failed. This document describes those
procedures in detail
Table of
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
The Session Initiation Protocol (SIP) (RFC 3261 [1]) is a client
server protocol used for the initiation and management
communications sessions between users. SIP end systems are
user agents, and intermediate elements are known as proxy servers.
typical SIP configuration, referred to as the SIP "trapezoid",
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
with proxy 1 in its domain (domain A). Proxy 1 forwards the
to the proxy for the domain of the called party (domain B), which
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
for domain B. To do this, proxy 1 makes use of DNS procedures,
both SRV [2] and NAPTR [3] records. This document describes
specific problems that SIP uses DNS to help solve, and provides
solution
2 Problems DNS is Needed to
DNS is needed to help solve two aspects of the general call
described in the Introduction. The first is for proxy 1 to
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
event it fails after forwarding the request
For the first aspect, proxy 1 specifically needs to determine the
address, port, and transport protocol for the server in domain B
The choice of transport protocol is particularly noteworthy.
many other protocols, SIP can run over a variety of
protocols, including TCP, UDP, and SCTP. SIP can also use TLS
Currently, use of TLS is defined for TCP only. Thus, clients need
be able to automatically determine which transport protocols
available. The proxy sending the request has a particular set
transport protocols it supports and a preference for using
transport protocols. Proxy 2 has its own set of transport
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
of DNS procedures are needed for proxy 1 to discover the
transport protocols for SIP services at domain B, and the
preferences of those transport protocols. Proxy 1 intersects
list of supported transport protocols with those of proxy 2 and
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
It is important to note that DNS lookups can be used multiple
throughout the processing of a call. In general, an element
wishes to send a request (called a client) may need to perform
processing to determine the IP address, port, and transport
of a next hop element, called a server (it can be a proxy or a
agent). Such processing could, in principle, occur at every
between elements
Since SIP is used for the establishment of interactive
services, the time it takes to complete a transaction between
caller and called party is important. Typically, the time from
the caller initiates a call until the time the called party
alerted should be no more than a few seconds. Given that there
be multiple hops, each of which is doing DNS lookups in addition
other potentially time-intensive operations, the amount of
available for DNS lookups at each hop is limited
Scalability and high availability are important in SIP. SIP
scale up through clustering techniques. Typically, in a
version of the network in Figure 1, proxy 2 would be a cluster
homogeneously configured proxies. DNS needs to provide the
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
and weights, in order to provide a crude level of capacity-based
balancing
SIP assures high availability by having upstream elements
failures. For example, assume that proxy 2 is implemented as
cluster of two proxies, proxy 2.1 and proxy 2.2. If proxy 1 sends
request to proxy 2.1 and the request fails, it retries the request
sending it to proxy 2.2. In many cases, proxy 1 will not know
domains it will ultimately communicate with. That information
be known when a user actually makes a call to another user in
domain. Proxy 1 may never communicate with that domain again
the call completes. Proxy 1 may communicate with thousands
different domains within a few minutes, and proxy 2 could
requests from thousands of different domains within a few minutes
Because of this "many-to-many" relationship, and the possibly
intervals between communications between a pair of domains, it is
generally possible for an element to maintain dynamic
state for the proxies it will communicate with. When a proxy
its first call with a particular domain, it will try the servers
that domain in some order until it finds one that is available.
identity of the available server would ideally be cached for
amount of time in order to reduce call setup delays of
calls. The client cannot query a failed server continuously
determine when it becomes available again, since this does not scale
Furthermore, the availability state must eventually be flushed
order to redistribute load to recovered elements when they come
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
to proxy 1, which is no longer available. The second aspect of
flow in the introduction for which DNS is needed, is for proxy 2
identify a backup for proxy 1 that it can send the response to.
problem is more realistic in SIP than it is in other
protocols. The reason is that some SIP responses can take a
time to be generated, because a human user frequently needs to
consulted in order to generate that response. As such, it is
uncommon for tens of seconds to elapse between a call request and
acceptance
Rosenberg & Schulzrinne Standards Track [Page 4]
RFC 3263 SIP: Locating SIP Servers June 2002
3
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]
indicate requirement levels for compliant SIP implementations
4 Client
Usage of DNS differs for clients and for servers. This
discusses client usage. We assume that the client is
(either a User Agent Client (UAC) or a stateful proxy).
proxies are discussed in Section 4.4.
The procedures here are invoked when a client needs to send a
to a resource identified by a SIP or SIPS (secure SIP) URI. This
can identify the desired resource to which the request is
(in which case, the URI is found in the Request-URI), or it
identify an intermediate hop towards that resource (in which case
the URI is found in the Route header). The procedures defined
in no way affect this URI (i.e., the URI is not rewritten with
result of the DNS lookup), they only result in an IP address,
and transport protocol where the request can be sent. RFC 3261 [1]
provides guidelines on determining which URI needs to be resolved
DNS to determine the host that the request needs to be sent to.
some cases, also documented in [1], the request can be sent to
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
of the form sip:, where is the FQDN or numeric
address of the next-hop proxy. As a result, in all cases,
problem boils down to resolution of a SIP or SIPS URI in DNS
determine the IP address, port, and transport of the host to
the request is to be sent
The procedures here MUST be done exactly once per transaction,
transaction is as defined in [1]. That is, once a SIP server
successfully been contacted (success is defined below),
retransmissions of the SIP request and the ACK for non-2xx
responses to INVITE MUST be sent to the same host. Furthermore,
CANCEL for a particular SIP request MUST be sent to the same
server that the SIP request was delivered to
Because the ACK request for 2xx responses to INVITE constitutes
different transaction, there is no requirement that it be
to the same server that received the original request (indeed,
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,
present, otherwise, the host value of the hostport component of
URI. It identifies the domain to be contacted. A description of
SIP and SIPS URIs and a definition of these parameters can be
in [1].
We determine the transport protocol, port and IP address of
suitable instance of TARGET in Sections 4.1 and 4.2.
4.1 Selecting a Transport
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
numeric IP address, the client SHOULD use UDP for a SIP URI, and
for a SIPS URI. Similarly, if no transport protocol is specified
and the TARGET is not numeric, but an explicit port is provided,
client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI. This
because UDP is the only mandatory transport in RFC 2543 [6], and
the only one guaranteed to be interoperable for a SIP URI. It
also specified as the default transport in RFC 2543 when no
was present in the SIP URI. However, another transport, such as TCP
MAY be used if the guidelines of SIP mandate it for this
request. That is the case, for example, for requests that exceed
path MTU
Otherwise, if no transport protocol or port is specified, and
target is not a numeric IP address, the client SHOULD perform a
query for the domain in the URI. The services relevant for the
of transport protocol selection are those with NAPTR service
with values "SIP+D2X" and "SIPS+D2X", where X is a letter
corresponds to a transport protocol supported by the domain.
specification defines D2U for UDP, D2T for TCP, and D2S for SCTP.
also establish an IANA registry for NAPTR service name to
protocol mappings
These NAPTR records provide a mapping from a domain to the SRV
for contacting a server with the specific transport protocol in
NAPTR services field. The resource record will contain an
regular expression and a replacement value, which is the SRV
for that particular transport protocol. If the server
multiple transport protocols, there will be multiple NAPTR records
each with a different service value. As per RFC 2915 [3], the
discards any records whose services fields are not applicable.
the purposes of this specification, several rules are defined
Rosenberg & Schulzrinne Standards Track [Page 6]
RFC 3263 SIP: Locating SIP Servers June 2002
First, a client resolving a SIPS URI MUST discard any services
do not contain "SIPS" as the protocol in the service field.
converse is not true, however. A client resolving a SIP URI
retain records with "SIPS" as the protocol, if the client
TLS. Second, a client MUST discard any service fields that
a resolution service whose value is not "D2X", for values of X
indicate transport protocols supported by the client. The
processing as described in RFC 2915 will result in the discovery
the most preferred transport protocol of the server that is
by the client, as well as an SRV record for the server. It will
allow the client to discover if TLS is available and its
for its usage
As an example, consider a client that wishes to
sip:user@example.com. The client performs a NAPTR query for
domain, and the following NAPTR records are returned
; order pref flags service regexp
IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com
IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.
IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com
This indicates that the server supports TLS over TCP, TCP, and UDP
in that order of preference. Since the client supports TCP and UDP
TCP will be used, targeted to a host determined by an SRV lookup
_sip._tcp.example.com. That lookup would return
;; Priority Weight Port
IN SRV 0 1 5060 server1.example.
IN SRV 0 2 5060 server2.example.
If a SIP proxy, redirect server, or registrar is to be
through the lookup of NAPTR records, there MUST be at least
records - one with a "SIP+D2T" service field, one with a "SIP+D2U
service field, and one with a "SIPS+D2T" service field. The
with SIPS as the protocol in the service field SHOULD be
(i.e., have a lower value of the order field) above records with
as the protocol in the service field. A record with a "SIPS+D2U
service field SHOULD NOT be placed into the DNS, since it is
possible to use TLS over UDP
It is not necessary for the domain suffixes in the NAPTR
field to match the domain of the original query (i.e., example.
above). However, for backwards compatibility with RFC 2543, a
MUST maintain SRV records for the domain of the original query,
if the NAPTR record is in a different domain. As an example,
though the SRV record for TCP is _sip._tcp.school.edu, there
also be an SRV record at _sip._tcp.example.com
Rosenberg & Schulzrinne Standards Track [Page 7]
RFC 3263 SIP: Locating SIP Servers June 2002
RFC 2543 will look up the SRV records for the domain directly.
these do not exist because the NAPTR replacement points to
different domain, the client will fail
For NAPTR records with SIPS protocol fields, (if the server is
a site certificate), the domain name in the query and the domain
in the replacement field MUST both be valid based on the
certificate handed out by the server in the TLS exchange. Similarly
the domain name in the SRV query and the domain name in the target
the SRV record MUST both be valid based on the same site certificate
Otherwise, an attacker could modify the DNS records to
replacement values in a different domain, and the client could
validate that this was the desired behavior or the result of
attack
If no NAPTR records are found, the client constructs SRV queries
those transport protocols it supports, and does a query for each
Queries are done using the service identifier "_sip" for SIP URIs
"_sips" for SIPS URIs. A particular transport is supported if
query is successful. The client MAY use any transport protocol
desires which is supported by the server
This is a change from RFC 2543. It specified that a client
lookup SRV records for all transports it supported, and merge
priority values across those records. Then, it would choose
most preferred record
If no SRV records are found, the client SHOULD use TCP for a
URI, and UDP for a SIP URI. However, another transport protocol
such as TCP, MAY be used if the guidelines of SIP mandate it for
particular request. That is the case, for example, for requests
exceed the path MTU
4.2 Determining Port and IP
Once the transport protocol has been determined, the next step is
determine the IP address and port
If TARGET is a numeric IP address, the client uses that address.
the URI also contains a port, it uses that port. If no port
specified, it uses the default port for the particular
protocol
If the TARGET was not a numeric IP address, but a port is present
the URI, the client performs an A or AAAA record lookup of the
name. The result will be a list of IP addresses, each of which
be contacted at the specific port from the URI and transport
Rosenberg & Schulzrinne Standards Track [Page 8]
RFC 3263 SIP: Locating SIP Servers June 2002
determined previously. The client SHOULD try the first record.
an attempt should fail, based on the definition of failure in
4.3, the next SHOULD be tried, and if that should fail, the
SHOULD be tried, and so on
This is a change from RFC 2543. Previously, if the port
explicit, but with a value of 5060, SRV records were used. Now,
or AAAA records will be used
If the TARGET was not a numeric IP address, and no port was
in the URI, the client performs an SRV query on the record
from the NAPTR processing of Section 4.1, if such processing
performed. If it was not, because a transport was
explicitly, the client performs an SRV query for that
transport, using the service identifier "_sips" for SIPS URIs. For
SIP URI, if the client wishes to use TLS, it also uses the
identifier "_sips" for that specific transport, otherwise, it
"_sip". If the NAPTR processing was not done because no
records were found, but an SRV query for a supported
protocol was successful, those SRV records are selected.
of how the SRV records were determined, the procedures of RFC 2782,
as described in the section titled "Usage rules" are followed
augmented by the additional procedures of Section 4.3 of
document
If no SRV records were found, the client performs an A or AAAA
lookup of the domain name. The result will be a list of
addresses, each of which can be contacted using the
protocol determined previously, at the default port for
transport. Processing then proceeds as described above for
explicit port once the A or AAAA records have been looked up
4.3 Details of RFC 2782
RFC 2782 spells out the details of how a set of SRV records
sorted and then tried. However, it only states that the
should "try to connect to the (protocol, address, service)"
giving any details on what happens in the event of failure.
details are described here for SIP
For SIP requests, failure occurs if the transaction layer reports
503 error response or a transport failure of some sort (generally
due to fatal ICMP errors in UDP or connection failures in TCP).
Failure also occurs if the transaction layer times out without
having received any response, provisional or final (i.e., timer B
timer F in RFC 3261 [1] fires). If a failure occurs, the
SHOULD create a new request, which is identical to the previous,
Rosenberg & Schulzrinne Standards Track [Page 9]
RFC 3263 SIP: Locating SIP Servers June 2002
has a different value of the Via branch ID than the previous (
therefore constitutes a new SIP transaction). That request is
to the next element in the list as specified by RFC 2782.
4.4 Consideration for Stateless
The process of the previous sections is highly stateful. When
server is contacted successfully, all retransmissions of the
for the transaction, as well as ACK for a non-2xx final response,
CANCEL requests for that transaction, MUST go to the same server
The identity of the successfully contacted server is a form
transaction state. This presents a challenge for stateless proxies
which still need to meet the requirement for sending all requests
the transaction to the same server
The problem is similar, but different, to the problem of
transactions within a cookie session getting routed to
servers based on DNS randomization. There, such distribution is
a problem. Farms of servers generally have common back-end
stores, where the session data is stored. Whenever a server in
farm receives an HTTP request, it takes the session identifier,
present, and extracts the needed state to process the request.
request without a session identifier creates a new one. The
with stateless proxies is at a lower layer; it is
requests within a transaction that are being potentially
across servers. Since none of these retransmissions carries
"session identifier" (a complete dialog identifier in SIP terms),
new dialog would be created identically at each server. This could
for example result in multiple phone calls to be made to the
phone. Therefore, it is critical to prevent such a thing
happening in the first place
The requirement is not difficult to meet in the simple case
there were no failures when attempting to contact a server.
the stateless proxy receives the request, it performs the
DNS queries as described above. However, the procedures of RFC 2782
are not guaranteed to be deterministic. This is because records
contain the same priority have no specified order. The
proxy MUST define a deterministic order to the records in that case
using any algorithm at its disposal. One suggestion is
alphabetize them, or, more generally, sort them by ASCII-
encoding. To make processing easier for stateless proxies, it
RECOMMENDED that domain administrators make the weights of
records with equal priority different (for example, using weights
1000 and 1001 if two servers are equivalent, rather than
both a weight of 1000), and similarly for NAPTR records. If
first server is contacted successfully, the proxy can
Rosenberg & Schulzrinne Standards Track [Page 10]
RFC 3263 SIP: Locating SIP Servers June 2002
stateless. However, if the first server is not
successfully, and a subsequent server is, the proxy cannot
stateless for this transaction. If it were stateless,
retransmission could very well go to a different server if the
one recovers between retransmissions. As such, whenever a proxy
not successfully contact the first server, it SHOULD act as
stateful proxy
Unfortunately, it is still possible for a stateless proxy to
retransmissions to different servers, even if it follows
recommendations above. This can happen if the DNS TTLs expire in
middle of a transaction, and the entries had changed. This
unavoidable. Network implementors should be aware of
limitation, and not use stateless proxies that access DNS if
error is deemed critical
5 Server
RFC 3261 [1] defines procedures for sending responses from a
back to the client. Typically, for unicast UDP requests,
response is sent back to the source IP address where the request
from, using the port contained in the Via header. For
transport protocols, the response is sent over the connection
request arrived on. However, it is important to provide
support when the client element fails between sending the request
receiving the response
A server, according to RFC 3261 [1], will send a response on
connection it arrived on (in the case of reliable
protocols), and for unreliable transport protocols, to the
address of the request, and the port in the Via header field.
procedures here are invoked when a server attempts to send to
location and that response fails (the specific conditions
detailed in RFC 3261). "Fails" is defined as any closure of
transport connection the request came in on before the response
be sent, or communication of a fatal error from the transport layer
In these cases, the server examines the value of the sent-
construction in the topmost Via header. If it contains a numeric
address, the server attempts to send the response to that address
using the transport protocol from the Via header, and the port
sent-by, if present, else the default for that transport protocol
The transport protocol in the Via header can indicate "TLS",
refers to TLS over TCP. When this value is present, the server
use TLS over TCP to send the response
Rosenberg & Schulzrinne Standards Track [Page 11]
RFC 3263 SIP: Locating SIP Servers June 2002
If, however, the sent-by field contained a domain name and a
number, the server queries for A or AAAA records with that name.
tries to send the response to each element on the resulting list
IP addresses, using the port from the Via, and the transport
from the Via (again, a value of TLS refers to TLS over TCP). As
the client processing, the next entry in the list is tried if the
before it results in a failure
If, however, the sent-by field contained a domain name and no port
the server queries for SRV records at that domain name using
service identifier "_sips" if the Via transport is "TLS", "_sip
otherwise, and the transport from the topmost Via header ("TLS
implies that the transport protocol in the SRV query is TCP).
resulting list is sorted as described in [2], and the response
sent to the topmost element on the new list described there. If
results in a failure, the next entry on the list is tried
6 Constructing SIP
In many cases, an element needs to construct a SIP URI for
in a Contact header in a REGISTER, or in a Record-Route header in
INVITE. According to RFC 3261 [1], these URIs have to have
property that they resolve to the specific element that
them. However, if they are constructed with just an IP address,
example
sip:1.2.3.4
then should the element fail, there is no way to route the request
response through a backup
SRV provides a way to fix this. Instead of using an IP address,
domain name that resolves to an SRV record can be used
sip:server23.provider.
The SRV records for a particular target can be set up so that
is a single record with a low value for the priority
(indicating the preferred choice), and this record points to
specific element that constructed the URI. However, there
additional records with higher values of the priority field
point to backup elements that would be used in the event of failure
This allows the constraint of RFC 3261 [1] to be met while
for robust operation
Rosenberg & Schulzrinne Standards Track [Page 12]
RFC 3263 SIP: Locating SIP Servers June 2002
7 Security
DNS NAPTR records are used to allow a client to discover that
server supports TLS. An attacker could potentially modify
records, resulting in a client using a non-secure transport when
is in fact available and preferred
This is partially mitigated by the presence of the sips URI scheme
which is always sent only over TLS. An attacker cannot force a
down through deletion or modification of DNS records. In the
case, they can prevent communication from occurring by deleting
records. A sips URI itself is generally exchanged within a
context, frequently on a business card or secure web page, or
a SIP message which has already been secured with TLS. See RFC 3261
[1] for details. The sips URI is therefore preferred when
is truly needed, but we allow TLS to be used for requests resolved
a SIP URI to allow security that is better than no TLS at all
The bid down attack can also be mitigated through caching. A
which frequently contacts the same domain SHOULD cache whether or
its NAPTR records contain SIPS in the services field. If
records were present, but in later queries cease to appear, it is
sign of a potential attack. In this case, the client SHOULD
some kind of alert or alarm, and MAY reject the request
An additional problem is that proxies, which are
between the users of the system, are frequently the clients
perform the NAPTR queries. It is therefore possible for a proxy
ignore SIPS entries even though they are present, resulting
downgraded security. There is very little that can be done
prevent such attacks. Clients are simply dependent on proxy
for call completion, and must trust that they implement the
properly in order for security to be provided. Falsifying
records can be done by tampering with wire traffic (in the absence
DNSSEC), whereas compromising and commandeering a proxy
requires a break-in, and is seen as the considerably less
downgrade threat
8 The Transport Determination
This section more formally defines the NAPTR usage of
specification, using the Dynamic Delegation Discovery System (DDDS
framework as a guide [7]. DDDS represents the evolution of the
resource record. DDDS defines applications, which can make use
the NAPTR record for specific resolution services. This
is called the Transport Determination Application, and its goal is
map an incoming SIP or SIPS URI to a set of SRV records for
various servers that can handle the URI
Rosenberg & Schulzrinne Standards Track [Page 13]
RFC 3263 SIP: Locating SIP Servers June 2002
The following is the information that DDDS requests an application
provide
Application Unique String: The Application Unique String (AUS)
the input to the resolution service. For this application,
is the URI to resolve
First Well Known Rule: The first well known rule extracts a
from the AUS. For this application, the first well known
extracts the host portion of the SIP or SIPS URI
Valid Databases: The key resulting from the first well known
is looked up in a single database, the DNS [8].
Expected Output: The result of the application is an SRV
for the server to contact
9 IANA
The usage of NAPTR records described here requires well known
for the service fields for each transport supported by SIP.
table of mappings from service field values to transport protocols
to be maintained by IANA. New entries in the table MAY be
through the publication of standards track RFCs, as described in
2434 [5].
The registration in the RFC MUST include the following information
Service Field: The service field being registered. An example
a new fictitious transport protocol called NCTP might
"SIP+D2N".
Protocol: The specific transport protocol associated with
service field. This MUST include the name and acronym for
protocol, along with reference to a document that describes
transport protocol. For example - "New
Transport Protocol (NCTP), RFC 5766".
Name and Contact Information: The name, address, email address
telephone number for the person performing the registration
The following values have been placed into the registry
Services Field
SIP+D2T
SIPS+D2T
SIP+D2U
SIP+D2S SCTP (RFC 2960)
Rosenberg & Schulzrinne Standards Track [Page 14]
RFC 3263 SIP: Locating SIP Servers June 2002
10
The authors would like to thank Randy Bush, Leslie Daigle,
Faltstrom, Jo Hornsby, Rohan Mahy, Allison Mankin, Michael Mealling
Thomas Narten, and Jon Peterson for their useful comments
11 Normative
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP
Session Initiation Protocol", RFC 3261, June 2002.
[2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR
Specifying the Location of Services (DNS SRV)", RFC 2782,
February 2000.
[3] Mealling, M. and R. Daniel, "The Naming Authority
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[4] Bradner, S., "Key Words for Use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Considerations Section in RFCs", BCP 26, RFC 2434,
1998.
12 Informative
[6] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
One: The Comprehensive DDDS Standard", Work in Progress
[8] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Three: The DNS Database", Work in Progress
Rosenberg & Schulzrinne Standards Track [Page 15]
RFC 3263 SIP: Locating SIP Servers June 2002
13 Authors'
Jonathan
72 Eagle Rock
First
East Hanover, NJ 07936
EMail: jdrosen@dynamicsoft.
Henning
Columbia
M/S 0401
1214 Amsterdam Ave
New York, NY 10027-7003
EMail: schulzrinne@cs.columbia.
Rosenberg & Schulzrinne Standards Track [Page 16]
RFC 3263 SIP: Locating SIP Servers June 2002
14 Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Rosenberg & Schulzrinne Standards Track [Page 17]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
