RFC 3263

Session Initiation Protocol (SIP): Locating SIP Servers

📅 published July 2002, from ietf

Session Initiation Protocol (SIP): Locating SIP Servers 💖

Okay so this is RFC 3263 🎀, written by J. Rosenberg (dynamicsoft) and H. Schulzrinne (Columbia U.) and published in June 2002. It's a Standards Track doc, and it obsoletes RFC 2543 ✨. Part 1 of 4, so stay with me bestie 🫶

Status of This Memo 🌸

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

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

Abstract ✨

SIP uses DNS procedures so a client can turn a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS so a server can send a response to a backup client if the primary client has failed. This document walks through 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
13         Authors' Addresses ..................................   16
14         Full Copyright Statement ............................   17

1. Introduction 👑

SIP (RFC 3261 [1]) is a client-server protocol for starting and managing communications sessions between users. SIP end systems are called user agents, and the middle elements are called proxy servers. A typical SIP setup, known as the SIP "trapezoid" 🔥, is shown in Figure 1. Here, a caller in domain A (UA1) wants to call Joe in domain B (joe@B). To do that, they talk to proxy 1 in their own domain (domain A). Proxy 1 forwards the request to the proxy for the called party's domain (domain B), which is proxy 2. Proxy 2 then forwards the call to the called party, UA 2 📞

As part of this call flow, proxy 1 needs to find a SIP server for domain B. To do that, it uses DNS procedures with both SRV [2] and NAPTR [3] records. This document describes the specific problems SIP uses DNS to help solve, and it gives a solution 💜

    ............................          ..............................
    .                          .          .                            .
    .                +-------+ .          . +-------+                  .
    .                |       | .          . |       |                  .
    .                | Proxy |------------- | Proxy |                  .
    .                |   1   | .          . |  2    |                  .
    .                |       | .          . |       |                  .
    .              / +-------+ .          . +-------+ \                .
    .             /            .          .            \               .
    .            /             .          .             \              .
    .           /              .          .              \             .
    .          /               .          .               \            .
    .         /                .          .                \           .
    .        /                 .          .                 \          .
    .       /                  .          .                  \         .
    .   +-------+              .          .                +-------+   .
    .   |       |              .          .                |       |   .
    .   |       |              .          .                |       |   .
    .   | UA 1  |              .          .                | UA 2  |   .
    .   |       |              .          .                |       |   .
    .   +-------+              .          .                +-------+   .
    .              Domain A    .          .   Domain B                 .
    ............................          ..............................

Figure 1: The SIP trapezoid

2. Problems DNS is Needed to Solve 🍓

DNS helps with two parts of the general call flow from the Introduction. The first is proxy 1 finding the SIP server in domain B so it can forward the call for joe@B. The second is proxy 2 finding a backup for proxy 1 in case proxy 1 fails after forwarding the request 😭

For the first part, proxy 1 specifically needs the IP address, port, and transport protocol for the server in domain B. The transport protocol is the really interesting bit ✨ Unlike a lot of other protocols, SIP can run over several transport protocols, including TCP, UDP, and SCTP. SIP can also use TLS, but right now TLS is only defined for TCP. So clients need a way to automatically figure out which transport protocols are available. The proxy sending the request has its own set of transport protocols it supports and a preference order for them. Proxy 2 has its own set and its own relative preferences too. All proxies must implement both UDP and TCP, along with TLS over TCP, so there's always an overlap in capabilities 🫶 Some form of DNS procedure is needed for proxy 1 to discover which transport protocols are available for SIP services at domain B, and how domain B ranks them. Proxy 1 then intersects its list of supported transport protocols with proxy 2's list and picks the one proxy 2 prefers 🎀

It's important to know that DNS lookups can happen many times while a call is being processed. In general, an element that wants to send a request (called a client) may need to do DNS processing to find the IP address, port, and transport protocol of a next hop element, called a server. That server can be a proxy or a user agent. In principle, this could happen at every hop between elements 🌸

Since SIP is used to set up interactive communications, the time it takes to finish a transaction between a caller and the called party really matters. Typically, the time from when the caller starts a call until the called party is alerted should be no more than a few seconds ⏱️ With multiple hops that each do DNS lookups alongside other potentially slow operations, the time available for DNS lookups at each hop is limited.

Scalability and high availability matter a lot in SIP 💅 SIP services scale up through clustering. In a realistic version of the network in Figure 1, proxy 2 would be a cluster of identically configured proxies. DNS needs to let domain B configure a set of servers, along with priorities and weights, so you get a basic level of capacity-based load balancing 🌈

SIP gets high availability by having upstream elements detect failures. For example, say proxy 2 is a cluster of two proxies, proxy 2.1 and proxy 2.2. If proxy 1 sends a request to proxy 2.1 and it fails, proxy 1 retries by sending the request to proxy 2.2. In many cases, proxy 1 won't know ahead of time which domains it will end up talking to. That only becomes clear when a user actually calls another user in that domain. Proxy 1 may never talk to that domain again after the call ends. Proxy 1 might talk to thousands of different domains within a few minutes, and proxy 2 could get requests from thousands of different domains in that same window 🦋 Because of this "many-to-many" relationship, and the long gaps that can happen between a pair of domains talking, an element generally can't keep up-to-the-moment availability state for every proxy it talks to. When a proxy gets its first call to a particular domain, it tries that domain's servers in some order until it finds one that's available. The identity of the available server would ideally be cached for a while so later calls set up faster 🍓 The client can't keep querying a failed server to check when it comes back, because that doesn't scale. And the availability state must eventually be flushed so load gets spread back out to recovered elements once they're online again 🔥

Elements can also 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 gone 💀 That's the second part of the introduction's call flow where DNS is needed: proxy 2 has to find a backup for proxy 1 to send the response to. This problem is more realistic in SIP than in other transactional protocols, because a human user often has to be consulted before some SIP responses can be generated. So it isn't unusual for tens of seconds to pass between a call request and its acceptance 🙈

3. Terminology 🧚

So in this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in RFC 2119 [4]. They're the requirement levels for compliant SIP implementations, so they matter a lot 💜

Heads up 🙈: the text for Sections 4.1, 4.2, 4.3, and 4.4 wasn't in this chunk, so I haven't written their sections yet rather than make anything up. Their titles and page numbers are in the table of contents above, and their full content will come through in the next part 🫶

4 Client Usage 💖

Okay bestie, DNS works differently for clients and servers 🧚. This section is all about the client side. We're assuming the client is stateful, so it's either a User Agent Client (UAC) or a stateful proxy 💅. Stateless proxies get their own moment in Section 4.4 ✨.

The procedures here kick in whenever a client needs to send a request to a resource identified by a SIP or SIPS (secure SIP) URI 🦋. That URI can be the actual target, found in the Request-URI, or it can be an intermediate hop, found in the Route header. Here's the lowkey important part: none of this touches the URI itself. We are NOT rewriting it with the DNS result 🙈. All we get out of it is an IP address, port and transport protocol where the request can be sent.

RFC 3261 [1] gives guidance on which URI needs to be resolved in DNS to find the host the request goes to ✨. In some cases, also documented in [1], the request can go to a specific intermediate proxy that's identified not by a SIP URI but by a hostname or numeric IP address. For that, a temporary URI gets built just for this specification, in the form sip:<proxy>, where proxy is the FQDN or numeric IP address of the next-hop proxy. So in every case, it boils down to resolving a SIP or SIPS URI in DNS to get the IP address, port, and transport of the host the request is headed to 🎀.

The procedures here MUST be done exactly once per transaction, and "transaction" means what [1] says it means 👑. 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. Very strict, very iconic 💅.

Because the ACK request for 2xx responses to INVITE is its own separate transaction, there is no requirement that it go to the same server that received the original request 🌸. Honestly, if that server didn't record-route, it won't even get the ACK 💀.

We define TARGET as the value of the maddr parameter of the URI, if present. Otherwise, it's the host value of the hostport component of the URI 🍓. It identifies the domain to be contacted. You can find a description of the SIP and SIPS URIs and a definition of these parameters 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 up, the client picks 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. Same vibe if no transport protocol is specified, 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. Why UDP? Because UDP is the only mandatory transport in RFC 2543 [6], so it's the only one guaranteed to be interoperable for a SIP URI 🤝. It was also the default transport in RFC 2543 when no transport was present in the SIP URI. That said, another transport, such as TCP, MAY be used if the guidelines of SIP mandate it for this particular request. Think 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 that matter for picking a transport are the ones with NAPTR service fields of "SIP+D2X" and "SIPS+D2X", where X is a letter that corresponds to a transport protocol the domain supports. This spec defines D2U for UDP, D2T for TCP, and D2S for SCTP. We also set up an IANA registry for NAPTR service name to transport protocol mappings 📋.

These NAPTR records map a domain to the SRV record for contacting a server with the specific transport protocol in the NAPTR services field. The resource record has an empty regular expression and a replacement value, which is the SRV record for that particular transport protocol. If the server supports multiple transport protocols, there will be multiple NAPTR records, each with a different service value. As per RFC 2915 [3], the client throws out any records whose services fields aren't applicable 🗑️. For this spec, a few rules get defined.

First, a client resolving a SIPS URI MUST discard any services that don't have "SIPS" as the protocol in the service field. The reverse isn't true, though. A client resolving a SIP URI SHOULD retain records with "SIPS" as the protocol, if the client supports TLS 🔐. Second, a client MUST discard any service fields that identify a resolution service whose value is not "D2X", for values of X that indicate transport protocols the client supports. NAPTR processing as described in RFC 2915 ends up finding the server's most preferred transport protocol that the client also supports, plus an SRV record for the server. It also lets the client figure out if TLS is available and how the server prefers to use it 🎯.

Let's do an example! 🎀 Say a client wants to resolve sip:user@example.com. It does a NAPTR query for that domain and gets back these NAPTR records:

;          order pref flags service      regexp  replacement
   IN NAPTR 50   50  "s"  "SIPS+D2T"     ""  _sips._tcp.example.com.
   IN NAPTR 90   50  "s"  "SIP+D2T"      ""  _sip._tcp.example.com
   IN NAPTR 100  50  "s"  "SIP+D2U"      ""  _sip._udp.example.com.

This tells us the server supports TLS over TCP, plain TCP, and UDP, in that order of preference 💅. The client supports TCP and UDP, so TCP wins, targeted to a host found by an SRV lookup of _sip._tcp.example.com. That lookup would return:

;;          Priority Weight Port   Target
       IN SRV  0        1      5060   server1.example.com
       IN SRV  0        2      5060   server2.example.com
Quick reminder: the NAPTR record with the lowest order wins, and the SIPS one at order 50 is the most preferred. Okay, now you're cooking 🍳.

If a SIP proxy, redirect server, or registrar is going to be contacted through a NAPTR lookup, there MUST be at least three records: one with a "SIP+D2T" service field, one with a "SIP+D2U" service field, and one with a "SIPS+D2T" service field 📚. The records with SIPS as the protocol in the service field SHOULD be preferred (meaning they get a lower value in the order field) over records with SIP as the protocol. A record with a "SIPS+D2U" service field SHOULD NOT be placed into the DNS, since TLS over UDP just isn't possible 🙅‍♀️.

The domain suffixes in the NAPTR replacement field don't have to match the domain of the original query (like example.com above) 🌍. But for backwards compatibility with RFC 2543, a domain MUST maintain SRV records for the domain of the original query, even if the NAPTR record points to a different domain. For example, even though the SRV record for TCP is _sip._tcp.school.edu, there MUST also be an SRV record at _sip._tcp.example.com. Honestly, this is the kind of rule that saves people from a 3am debugging session 😭.

RFC 2543 looks up the SRV records for the domain directly. If those don't exist because the NAPTR replacement points to a different domain, the client will fail. Yikes 💀.

For NAPTR records with SIPS protocol fields (if the server is using a site certificate), the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate the server hands out in the TLS exchange 🔒. Likewise, the domain name in the SRV query and the domain name in the target of the SRV record MUST both be valid based on that same site certificate. Otherwise, an attacker could change the DNS records to point to replacement values in a different domain, and the client couldn't tell whether that was the desired behavior or the result of an attack. Scary stuff, so please don't skip this 🫣.

If no NAPTR records are found, the client builds SRV queries for the transport protocols it supports and does a query for each one 🧩. Queries use the service identifier "_sip" for SIP URIs and "_sips" for SIPS URIs. A particular transport counts as supported if its query is successful. The client MAY use any transport protocol it desires that is supported by the server 🦋.

This is a change from RFC 2543. That one had the client look up SRV records for all the transports it supported, merge the priority values across those records, and then choose the most preferred record. Plot twist, we don't do that anymore 🙃.

If no SRV records are found, the client SHOULD use TCP for a SIPS 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 this particular request. That's the case, for example, for requests that exceed the path MTU 💜.

4.2 Determining Port and IP Address ✨

okay so once the transport protocol is locked in, the next step is figuring out the IP address and port 🦋

If TARGET is a numeric IP address, the client just uses that address 💖 If the URI also has a port, it uses that port. If there's no port, it falls back to the default port for the transport protocol 🎀

If TARGET is not a numeric IP address but there IS a port in the URI, the client does an A or AAAA record lookup on the domain name 🌸 The result is a list of IP addresses, and each one can be contacted at that specific port and the transport protocol we picked earlier. The client SHOULD try the first record. If an attempt fails (the definition of failure is in Section 4.3, bestie 💅), the next SHOULD be tried, and if that one fails too, the next SHOULD be tried, and so on 🍓

This is a change from RFC 2543. Back then, if the port was explicit but set to 5060, SRV records were used. Now it's A or AAAA records instead 🙈

If TARGET is not a numeric IP address and no port is in the URI, the client does an SRV query on the record returned from the NAPTR processing in Section 4.1, if that processing happened 🧚 If it didn't, because a transport was set explicitly, the client does an SRV query for that specific transport, using the service identifier _sips for SIPS URIs. For a SIP URI, if the client wants to use TLS, it also uses the service identifier _sips for that transport. Otherwise, it uses _sip 💜

If NAPTR processing was skipped because no NAPTR records were found, but an SRV query for a supported transport protocol worked, those SRV records get selected ✨ Regardless of how the SRV records were found, 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 this document 👑

If no SRV records were found, the client does an A or AAAA record lookup on the domain name. The result is a list of IP addresses, each of which can be contacted using the transport protocol determined previously, at the default port for that transport. Processing then proceeds as described above for an explicit port once the A or AAAA records have been looked up 🫶

4.3 Details of RFC 2782 Process 🦋

RFC 2782 spells out the details of how a set of SRV records gets sorted and then tried. However, it only says the client should "try to connect to the (protocol, address, service)" without giving any details on what happens when things go wrong 🙈 Those details are described here for SIP 💅

For SIP requests, failure happens if the transaction layer reports a 503 error response, or a transport failure of some sort (usually from fatal ICMP errors in UDP or connection failures in TCP) 💀 Failure also happens if the transaction layer times out without ever receiving any response, provisional or final. That's when timer B or timer F in RFC 3261 [1] fires ⏰

If a failure happens, the client SHOULD create a new request. It's identical to the previous one, but it has a different value of the Via branch ID than before, which makes it a brand new SIP transaction 🌈 That request is then sent to the next element in the list, as specified by RFC 2782 ✨

4.4 Consideration for Stateless Proxies 🔥

The process in the previous sections is highly stateful, bestie 😭 When a server is contacted successfully, all retransmissions of the request for the transaction, plus the ACK for a non-2xx final response, and CANCEL requests for that transaction, MUST go to the same server 🎀

The identity of the successfully contacted server is a form of transaction state. This is a challenge for stateless proxies, which still need to meet the requirement of sending all requests in the transaction to the same server 💜

The problem is similar to, but different from, HTTP transactions in a cookie session getting routed to different servers because of DNS randomization. There, that distribution is not a problem 🌸 Farms of servers usually share common back-end data stores where the session data lives. Whenever a server in the farm gets an HTTP request, it takes the session identifier (if one is present) and extracts the state it needs to process the request. A request without a session identifier creates a new one 🧚

The stateless proxy problem happens at a lower layer. It's retransmitted requests within a transaction that might get spread across servers 😱 None of these retransmissions carries a "session identifier" (a complete dialog identifier in SIP terms), so a new dialog would be created identically at each server. This could, for example, result in multiple phone calls being made to the same phone 📞 Therefore, it is critical to prevent this from happening in the first place. 🚨

The requirement is not difficult to meet in the simple case where there were no failures when contacting a server. Whenever the stateless proxy receives the request, it does the appropriate DNS queries as described above 🍓 However, the procedures of RFC 2782 are not guaranteed to be deterministic, because records with the same priority have no specified order 🙃 The stateless proxy MUST define a deterministic order for the records in that case, using any algorithm it has available. One suggestion is to alphabetize them or, more generally, sort them by ASCII-compatible encoding 🔤

To make processing easier for stateless proxies, it is RECOMMENDED that domain administrators make the weights of SRV records with equal priority different. For example, use weights of 1000 and 1001 if two servers are equivalent, rather than assigning both a weight of 1000. The same goes for NAPTR records 💅

If the first server is contacted successfully, the proxy can stay stateless ✨ However, if the first server is not contacted successfully and a subsequent server is, the proxy cannot stay stateless for this transaction. If it did, a retransmission could easily go to a different server if the failed one recovers between retransmissions 😬 So whenever a proxy does not successfully contact the first server, it SHOULD act as a stateful proxy 🫶

Unfortunately, it's still possible for a stateless proxy to deliver retransmissions to different servers, even if it follows the recommendations above. This can happen if the DNS TTLs expire in the middle of a transaction and the entries had changed. This is unavoidable 💀 Network implementors should be aware of this limitation, and should not use stateless proxies that access DNS if this error is deemed critical 👑

5 Server Usage 🎀

RFC 3261 [1] defines the procedures for sending responses from a server back to the client 💖 Typically, for unicast UDP requests, the response goes back to the source IP address where the request came from, using the port in the Via header. For reliable transport protocols, the response is sent over the connection the request arrived on. But it's important to provide failover support in case the client element fails between sending the request and receiving the response 🦋

A server, according to RFC 3261 [1], sends a response on the connection the request arrived on (for reliable transport protocols), and for unreliable transport protocols, to the source address of the request and the port in the Via header field. The procedures here kick in when a server tries to send to that location and the response fails (the specific conditions are detailed in RFC 3261). "Fails" is defined as any closure of the transport connection the request came in on before the response can be sent, or communication of a fatal error from the transport layer 😱

In these cases, the server looks at the value of the sent-by construction in the topmost Via header. If it contains a numeric IP address, the server tries to send the response to that address, using the transport protocol from the Via header, and the port from sent-by if present, otherwise the default for that transport protocol 🧚 The transport protocol in the Via header can indicate "TLS", which refers to TLS over TCP. When this value is present, the server MUST use TLS over TCP to send the response 🔒

If, however, the sent-by field contained a domain name and a port number, the server queries for A or AAAA records with that name. It tries to send the response to each element on the resulting list of IP addresses, using the port from the Via and the transport protocol from the Via (again, a value of TLS refers to TLS over TCP). Just like in the client processing, the next entry in the list is tried if the one before it fails 🌸

If, however, the sent-by field contained a domain name and no port, the server queries for SRV records at that domain name. It uses the service identifier _sips if the Via transport is "TLS", and _sip otherwise, plus the transport from the topmost Via header ("TLS" means the transport protocol in the SRV query is TCP). The resulting list is sorted as described in [2], and the response is sent to the topmost element on the new list described there. If that fails, the next entry on the list is tried 🍓

6 Constructing SIP URIs 🌈

In many cases, an element needs to build a SIP URI to include in a Contact header in a REGISTER, or in a Record-Route header in an INVITE 💜 According to RFC 3261 [1], these URIs have to resolve to the specific element that inserted them. But if they're built with just an IP address, like this:

sip:1.2.3.4

then, should the element fail, there's no way to route the request or response through a backup 😭

SRV provides a way to fix this 🎀 Instead of an IP address, you can use a domain name that resolves to an SRV record:

sip:server23.provider.com

The SRV records for a particular target can be set up so there's a single record with a low value for the priority field (the preferred choice), and this record points to the specific element that built the URI. There are also additional records with higher priority values that point to backup elements, which would be used if something fails 🦋 This lets the constraint of RFC 3261 [1] be met while still allowing for robust operation ✨

7. Security Considerations 🔒✨

Okay bestie, security time 😭🔒 DNS NAPTR records are how a client finds out that the server supports TLS 🫶 But an attacker could sneakily change those records, so the client ends up on a non-secure transport even though TLS was actually there and preferred 💀

This is partially covered by the sips URI scheme 🎀 A sips URI is always sent only over TLS, and an attacker can't force a bid down by deleting or changing DNS records. The worst they can do is stop communication from happening at all by deleting every record 🙈 A sips URI usually gets passed around in a secure context, like on a business card or a secure web page, or inside a SIP message that's already secured with TLS. See RFC 3261 [1] for details 📖 So the sips URI is the one to use when security is truly needed 💜 We still let TLS be used for requests resolved by a SIP URI, though, because security that's better than no TLS at all is still a win 🌸

The bid down attack can also be stopped with caching 🧠 A client that keeps contacting the same domain SHOULD cache whether or not its NAPTR records include SIPS in the services field. If those records were there before but stop showing up in later queries, that's a sign of a potential attack 👀 In that case the client SHOULD generate some kind of alert or alarm, and MAY reject the request 🚨

Here's the plot twist 😤 Proxies are the middlemen between users, and they're often the ones doing the NAPTR queries. So a proxy could ignore SIPS entries even when they're there, and security gets downgraded 💀 There's really not much that can be done about this. Clients just depend on proxy servers to complete calls, and they have to trust that those proxies implement the protocol properly if they want security 🥺 Faking DNS records means tampering with wire traffic (when DNSSEC isn't in use), but compromising and taking over a proxy server takes an actual break-in, so that's seen as the much less likely downgrade threat 🕵️‍♀️✨

8. The Transport Determination Application 🦋

This section formally defines how this specification uses NAPTR, using the Dynamic Delegation Discovery System (DDDS) framework as a guide [7] 🧚 DDDS is basically the evolution of the NAPTR resource record 💅 DDDS defines applications that can make use of NAPTR records for specific resolution services. This application is called the Transport Determination Application, and its goal is to map an incoming SIP or SIPS URI to a set of SRV records for the various servers that can handle that URI 🎯

Here's what DDDS asks an application to provide 📝

  • Application Unique String: The Application Unique String (AUS) is the input to the resolution service. For this application, it is the URI to resolve.
  • First Well Known Rule: The first well known rule extracts a key from the AUS. For this application, the first well known rule extracts the host portion of the SIP or SIPS URI.
  • Valid Databases: The key resulting from the first well known rule is looked up in a single database, the DNS [8].
  • Expected Output: The result of the application is an SRV record for the server to contact.

9. IANA Considerations 📋

Using NAPTR records the way this document describes needs well known values for the service fields, one for each transport that SIP supports 🌈 The table that maps service field values to transport protocols is maintained by IANA 🗂️ New entries MAY be added through the publication of standards track RFCs, as described in RFC 2434 [5] ✨

The registration in the RFC MUST include the following information 📝

  • Service Field: The service field being registered. An example for a new fictitious transport protocol called NCTP might be "SIP+D2N".
  • Protocol: The specific transport protocol associated with that service field. This MUST include the name and acronym for the protocol, along with a reference to a document that describes the transport protocol. For example, "New Connectionless Transport Protocol (NCTP), RFC 5766".
  • Name and Contact Information: The name, address, email address and telephone number for the person performing the registration.

The following values have been placed into the registry 🧁

Services Field               Protocol
SIP+D2T                       TCP
SIPS+D2T                      TCP
SIP+D2U                       UDP
SIP+D2S                       SCTP (RFC 2960)

10. Acknowledgements 🫶

The authors want to thank Randy Bush, Leslie Daigle, Patrik Faltstrom, Jo Hornsby, Rohan Mahy, Allison Mankin, Michael Mealling, Thomas Narten, and Jon Peterson for their useful comments 💖 Iconic squad 👑

11. Normative References 📚

  • [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 for Specifying the Location of Services (DNS SRV)", RFC 2782, February 2000.
  • [3] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.
  • [4] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

12. Informative References 💡

  • [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) Part One: The Comprehensive DDDS Standard", Work in Progress.
  • [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database", Work in Progress.

13. Authors' Addresses 💌

Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936

EMail: jdrosen@dynamicsoft.com


Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003

EMail: schulzrinne@cs.columbia.edu

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

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society. 💜

📦 where this page comes from