Subject: Re: Please comment on my draft: DHCP Option for Call Control

From: Rich Woundy <[email-masked]>
Date: Tue, 2 Feb 1999 15:55:17 -0500 (EST)

Henry,

I am one of many folks that are anticipating deployments of millions of
voice over IP hosts for residential phone service. These hosts are often
called "residential gateways". It does make sense for most of these
residential gateways to obtain call gateway/call agent information from
DHCP. Many of these gateways may be devices such as cable modems that
already obtain configuration from DHCP (other examples of residential
gateways include set-top boxes, xDSL devices, and broadband wireless devices).

While I like the concept of your draft, this draft looks like it supports
"NBX Call Control Servers" only, which I assume is a vendor product. What
protocol(s) do these NBX servers support? I would think that the Internet
community needs support in this realm for more standard VoIP protocols,
such as H.323 and MGCP, as well as other up-and-coming protocols (DOSA?).

While I am not a VoIP expert, I do know that there are several special
configuration considerations for MGCP:

1. The call agents are identified by *domain names*, not by IP addresses.
2. The residential gateway needs a "digit map" that tells it how to collect
the numbers dialed on the phone, before it sends them to the call agent.
3. The residential gateway may support several RJ-11 ports on one IP host.
Each port is identified by an endpoint name, xxx@yyy, which is supposed to
emulate an email address. Each RJ-11 port may get its own call agent and
digit map.

Should we work on this together? Who else is interested?

-- Rich

P.S. More information about MGCP can be found at:

http://search.ietf.org/internet-drafts/draft-huitema-mgcp-v0r1-02.txt
http://search.ietf.org/internet-drafts/draft-huitema-mgcp-flows-00.txt
http://sgcp.bellcore.com

At 05:37 PM 1/26/99 -0500, Henry Houh wrote:
>
>Hi,
>
>I'm new to this process so I don't know the procedure, though I have
>read the info for new IETF folks and other info that I have been able
>to find.  If I have submitted this in an improper fashion or not named
>it correctly, please let me know the correct way to get this in front
>of the working group.
>
>I would like to introduce a draft for a new DHCP option to support
>location of call control servers (like an H.323 gatekeeper).  There
>are many new products available that have stand-alone IP-telephone
>endpoints.  This option would facilitate the setup of these endpoints
>so as to eliminate any configuration necessary for these IP telephones
>to locate their call control servers.
>
>I have tried to do this in a way that allows other vendors with
>products to add to this option, but I would like comments on whether
>the method to add a new sub-option is acceptable - I have tried to
>mirror the method new options are added, and this may be too
>heavyweight a method.  Also, I have not made any assumptions on who
>else would like to use this option.
>
>Comments on the draft are appreciated,
>
>Thanks,
>
>Henry Houh
>NBX Corporation
>
>
>
>
>Internet Engineering Task Force                               Henry Houh
>INTERNET DRAFT                                           NBX Corporation
>                                                           November 1998
>                                                        Expires May 1999
>
>
>               DHCP Options for Call Control Servers
>              <draft-ietf-dhc-callcontrolserv-00.txt>
>
>Status of This Memo
>
>   This document is a submission to the Dynamic Host Configuration
>   Working Group of the Internet Engineering Task Force (IETF). Comments
>   should be submitted to the [email-masked] mailing list.
>
>   Distribution of this memo is unlimited.
>
>   This document is an Internet-Draft.  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.''
>
>   To learn the current status of any Internet-Draft, please check
>   the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
>   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North
>   Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim),
>   ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
>
>Abstract
>
>   This document defines a new DHCP option for delivering configuration
>   information to telephony enabled hosts in order to locate a call
>   control/signalling server.  The option carries several operational
>   parameters that allow multiple call control vendors to utilize this
>   field.
>
>1. Introduction
>
>   Telephony is emerging as a network-based application.  The Call
>   Control Server option allows telephony or gateway devices which
>   cannot independently setup up and signal calls to automatically
>   discover an address of a call control server.
>
>
>
>
>Houh                        Expires May 1999                    [Page 1]
>
>Internet Draft   DHCP Option for Call Control Servers      November 1998
>
>
>   This specification describes a DHCP option [1] that can carry one or
>   several Call Control Server sub-options.  Each sub-option is
>   treated as a separate potential call control server by the hosts.
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in RFC 2119. [2]
>
>2. Call Control Server Option
>
>   This option specifies one or more fields carrying Call Control
>   Server information.  The fields that can be carried by this option
>   are described in the sections that follow.
>
>   The code for this option is TBD, and its maximum length is 255 octets.
>
>      Code   Len        Sub-Option 1               Sub-Option 2
>     +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+--
>     | TBD |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  a3 |  a4 |  ...
>     +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+--
>
>   The 'Len' field specifies the number of octets containing sub-option
>   information within the DHCP option.
>
>   Each sub-option will contain a code followed by a length that
>   specifies the number of octets containing configuration parameter
>   information within the sub-option.
>
>      Sub    Sub 
>      Code   Len        Configuration Parameter(s)
>     +-----+-----+-----+-----+-----+-----+-----+-----+--
>     |  x  |  n  |  a1 |  a2 |  a3 |  a4 |  a6 |  a7 |  ...
>     +-----+-----+-----+-----+-----+-----+-----+-----+--
>
>2.1. Call Control Servers
>
>   This section describes the vendor-specific sub-options.
>
>   Other types/vendors of call control servers can be added by using 
>   new sub-option fields.  See section 2.2 for the procedure for
>   adding sub-option fields.
>
>2.1.1 NBX Call Control Server Sub-option
>
>   This sub-option specifies the network address of an NBX Call
>   Control Server.
>
>
>
>
>
>Houh                        Expires May 1999                    [Page 2]
>
>Internet Draft   DHCP Option for Call Control Servers      November 1998
>
>
>   The code for this sub-option is 1. The length specified in the 'Len'  
>   field of this sub-option MUST always be 4 octets.
>
>      Code   Len    NBX Server Address
>     +-----+-----+-----+-----+-----+-----+
>     |  1  |  4  |  a1 |  a2 |  a3 |  a4 |
>     +-----+-----+-----+-----+-----+-----+
>
>2.2 Procedure for adding call control server types
>
>   A vendor may add a new sub-option field by issuing an internet
>   draft that contains the new sub-option.  The new sub-option field
>   code MUST be labeled "TBD."  This draft will then be submitted to
>   the DHC working group, and, if accepted for inclusion in the DHCP
>   specification, a sub-option field code is assigned and the
>   sub-option specification is published as an RFC which updates this
>   RFC.
>
>3. Using Multiple Sub-options
>
>   More than one sub-option field MAY be returned to the host.
>   In addition, more than one of any sub-option type MAY be present.
>   This allows the host to select the call control server appropriate
>   to own its signaling protocol, allowing a single DHCP server to
>   support multiple homogeneous call control servers as well as
>   heterogeneous telephony and gateway devices.
>
>4. References
>
>   [1] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
>       Extensions", RFC-2132, March 1997.
>
>   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
>       Levels", RFC-2119, March 1997.
>
>   [3] Droms, R., "Dynamic Host Configuration Protocol", RFC-2131,
>       March 1997.
>
>5. Security Considerations
>
>   DHCP currently provides no authentication or security mechanisms.
>   Potential exposures to attack are discussed in section 7 of the DHCP
>   protocol specification [3]. In particular, these DHCP options allow
>   an unauthorized DHCP server to misdirect a telephone or gateway
>   host to an unauthorized call control server.
>
>
>
>
>
>
>Houh                        Expires May 1999                    [Page 3]
>
>Internet Draft   DHCP Option for Call Control Servers      November 1998
>
>
>6. Author's Address
>
>   Henry Houh   
>   NBX Corporation
>   100 Brickstone Square
>   Andover, MA  01810
>
>   Phone: +1 978 740 0000 x257
>
>   EMail: [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Houh                        Expires May 1999                    [Page 4]
>