RFC 3361 (rfc3361) - Page 2 of 7
Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers
Alternative Format: Original Text Document
RFC 3361 DHCPv4 Option for SIP Servers August 2002
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].
2. Introduction
The Session Initiation Protocol (SIP) [2] is an application-layer
control protocol that can establish, modify and terminate multimedia
sessions or calls. A SIP system has a number of logical components:
user agents, proxy servers, redirect servers and registrars. User
agents MAY contain SIP clients, proxy servers always do.
This document specifies a DHCP option [1,5] that allows SIP clients
to locate a local SIP server that is to be used for all outbound SIP
requests, a so-called outbound proxy server. (SIP clients MAY
contact the address identified in the SIP URL directly, without
involving a local SIP server. However in some circumstances, for
example, when firewalls are present, SIP clients need to use a local
server for outbound requests.) This is one of many possible
solutions for locating the outbound SIP server; manual configuration
is an example of another.
3. SIP Server DHCP Option
The SIP server DHCP option carries either a 32-bit (binary) IPv4
address or, preferably, a DNS (RFC 1035 [6]) fully-qualified domain
name to be used by the SIP client to locate a SIP server.
The option has two encodings, specified by the encoding byte ('enc')
that follows the code byte. If the encoding byte has the value 0, it
is followed by a list of domain names, as described below (Section
3.1). If the encoding byte has the value 1, it is followed by one or
more IPv4 addresses (Section 3.2). All implementations MUST support
both encodings. The 'Len' field indicates the total number of octets
in the option following the 'Len' field, including the encoding byte.
A DHCP server MUST NOT mix the two encodings in the same DHCP
message, even if it sends two different instances of the same option.
Attempts to do so would result in incorrect client behavior as DHCP
processing rules call for the concatenation of multiple instances of
an option into a single option prior to processing the option [7].
The code for this option is 120.
Schulzrinne Standards Track