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