Internet Engineering Task Force SIP WG
Internet Draft G.Nair, H.Schulzrinne
draft-ietf-sip-dhcp-01.txt Columbia University
April 6, 2000
Expires: October 2000
DHCP Option for SIP Servers
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document defines a DHCP option that contains a pointers to one
or more SIP servers. This is one of the many methods that a SIP
client can use to obtain the addresses of a local oubound SIP server.
Table of Contents
1 Terminology ......................................... 2
2 Introduction ........................................ 2
3 Overview ............................................ 2
4 SIP server DHCP options ............................. 2
5 Security Consideration .............................. 3
6 Acknowledgements .................................... 3
7 Authors' Addresses .................................. 4
8 Bibliography ........................................ 4
G.Nair, H.Schulzrinne [Page 1]
Internet Draft April 6, 2000
1 Terminology
DHCP client: A DHCP [1] client is an Internet host that uses
DHCP to obtain configuration parameters such as a network
address.
DHCP server: A DHCP server is an Internet host that returns
configuration parameters to DHCP clients.
SIP server: As defined in RFC 2543 [2]. In the context of this
document, a SIP server refers to the host the SIP server is
running on.
SIP client: As defined in RFC 2543. In the context of this
document, a SIP client refers to the host the SIP client is
running on.
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 [3].
2 Introduction
The Session Initiation Protocol (SIP) [2] is an application-layer
control protocol that can establish, modify and terminate multimedia
sessions or calls. In particular, it is used for signaling of
Internet telephony calls. A SIP system has two components: user
agents and servers. The user agent is the SIP end system that acts
on behalf of someone who wants to participate in a SIP call.
This draft specifies a DHCP option [1,4] that allows SIP user agents
(clients) to locate a local SIP server that is to be used for all
outbound SIP requests. (SIP clients MAY contact the address
identified in the SIP URL directly, without involving a local SIP
server. However in some circumstances, 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.
3 Overview
The SIP client obtains a DNS [5] string via a DHCP option. The SIP
client first uses the SRV [6] resource records to resolve the host
name. If this fails, the A resource records are tried.
4 SIP server DHCP options
This option specifies the DNS [5] string that is passed to the
G.Nair, H.Schulzrinne [Page 2]
Internet Draft April 6, 2000
client. This string SHOULD be the domain name of the SIP server. The
client SHOULD first use this string to send an SRV query to the DNS
server. If the client is not SRV-cognizant or the SRV query fails,
the client sends the same string in an A record query. The code for
this option is TBD. The length of the DNS name string is specified in
`Len'. The maximum length of this string is 255 octets and minimum
length is 1 octet.
Code Len DNS name of SIP server
+-----+-----+-----+-----+-----+-----+-----+--
| TBD | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+--
The reason for using the SRV string to obtain the IP address is that
load sharing can be implemented more readily by an SRV-cognizant
client. The string sent by the DHCP server SHOULD be the domain name
of the SIP server. The client uses this string to construct the SRV
query. The DHCP server MAY instead choose to send the fully qualified
domain name of the SIP server intended to be used in an A record
query, but this is NOT RECOMMENDED. The client however, MUST first
treat the string as a domain name and use it to construct the SRV
query. SIP clients usually support either UDP or TCP, but SIP
servers usually support both UDP and TCP. Thus, if the string sent
by the DHCP server is intended for use in constructing the SRV query,
it MUST NOT contain the Service and Proto [6] fields. The client is
aware of the transport protocols that it can support, therefore it is
appropriate that the Service and the Proto fields be added by the
client. The Service field in this case is always _sip. The Proto
fields may be _udp or _tcp depending on the client's capabilities.
The client adds the Service and Proto fields to the string before
making the SRV query. If the client's SRV query fails, the client
MUST use the string originally returned by the DHCP server in an A
record query (without adding the Service and Proto fields).
5 Security Consideration
There are no security considerations beyond those described in RFC
2132.
6 Acknowledgements
We would like to thank Robert Elz, Wenyu Jiang, Peter Koch, Erik
Nordmark, Jonathan Rosenberg, Kundan Singh, Sven Ubik and Bernie Volz
for their contributions.
G.Nair, H.Schulzrinne [Page 3]
Internet Draft April 6, 2000
7 Authors' Addresses
Gautam Nair
Dept. of Computer Science
Columbia University 1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
electronic mail: gnair@cs.columbia.edu
Henning Schulzrinne
Dept. of Computer Science
Columbia University 1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
electronic mail: schulzrinne@cs.columbia.edu
8 Bibliography
[1] R. Droms, "Dynamic host configuration protocol," Request for
Comments (Draft Standard) 2131, Internet Engineering Task Force, Mar.
1997.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments (Proposed
Standard) 2543, Internet Engineering Task Force, Mar. 1999.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments (Best Current Practice) 2119, Internet
Engineering Task Force, Mar. 1997.
[4] S. Alexander and R. Droms, "DHCP options and BOOTP vendor
extensions," Request for Comments (Draft Standard) 2132, Internet
Engineering Task Force, Mar. 1997.
[5] P. V. Mockapetris, "Domain names - implementation and
specification," Request for Comments (Standard) 1035, Internet
Engineering Task Force, Nov. 1987.
[6] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying
the location of services (DNS SRV)," Request for Comments (Proposed
Standard) 2782, Internet Engineering Task Force, Feb. 2000.
Full Copyright Statement
Copyright (c) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
G.Nair, H.Schulzrinne [Page 4]
Internet Draft April 6, 2000
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.
G.Nair, H.Schulzrinne [Page 5]