Subject: DHCP option tags for SIP

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Feb 2000 09:29:13 -0500

Folks,

Many of you may have seen the recent draft presenting DHCP option codes
for SIP:

http://search.ietf.org/internet-drafts/draft-nair-sip-dhcp-01.txt

The consensus among the authors and wg chairs is that this is a clearly
useful item, and we would like to move it forward. In the interests of
speed, we are proposing a "fast track" approach for this document.
Basically, this message will serve as announcement of our intention to
adopt this as a work item. If no one objects to this procedure, in one
weeks time, we will issue an extended working group last call on it, and
that call will last 3 weeks. Comments will be collected, and then we
will send the document to IESG for proposed.

I believe its critical that we do whatever we can to speed up the
process of delivering documents to the community. This is especially the
case for small, largely uncontroversial documents such as this. Rather
than languish for months, getting this from concept to submission to
IESG in a matter of a single month seems more desirable.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Feb 2000 09:41:42 -0800 (PST)

I'd like to throw out one wet blanket: getting the
name of a first hop proxy is all well and good,
but it hardly solves the larger provisioning
problem, especially for "simple" phones and other
devices which don't have an easy way to be
configured by a user, or want/need to be centrally
managed. Trying to cram bootstrap provisioning for
N different kinds of protocols/devices into one
MTU sized packet seems like a losing situation and
symptomatic that DHCP is being used for way more
than it can deliver in the long run.

It seems to me that it would be far better to
create some sort of indirection method within DHCP
which says "here's the URL if you want to get SIP
related parameters" (ad naseum). 

But all that's being asked for is "just" the
address of the first hop proxy... sigh.

	   Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 18 Feb 2000 13:23:09 -0500

> than it can deliver in the long run.

As far as I can tell from our implementation experience, this is pretty
much (*) the last piece of information needed to configure a phone. At
the DHCP level, we currently use for a basic phone:

- IP address, DNS server address, default gateway (standard DHCP fare)
- time server address
- outbound SIP proxy server
- normal boot image information for phones with downloadable code

We have to implement DHCP in any event, so the incremental cost of
providing this is close to zero.

There are other SIP-level configurations that are inappropriate, in my
view, for DHCP, things like speed dial configurations or other UI
assignments, any end system CPL, etc.

> address of the first hop proxy... sigh.

As I said, this is necessary and sufficient to get working phones, from
what I can tell.

---

From: Francois Menard List Account <[email-masked]>
Date: Sat, 19 Feb 2000 08:40:36 -0500 (EST)

The option is SLP I think .... DHCP as a bootstrap protocol doesn't ring
too well with me.

-=Francois=-

---

From: Michael Thomas <[email-masked]>
Date: Sat, 19 Feb 2000 09:10:55 -0800 (PST)

So, let me poke at this a bit: 

1) if I have a residential gateway, say, which runs 
   SIP on its two POTS lines, with SLP can I find 
   the (different) first hop proxies for each port? 
2) Suppose I have some IP phones at home which are
   gateway'd through my home SIP proxy which allow
   me to set up local dial plans. Would SLP be adequate
   to configure the 1) phones 2) my home proxy for learning
   their next hope proxy?

I'm not trying to diss the idea, but SLP seems to
have been written with enterprises in mind --
which is fine -- but the more complicated
situations will probably need to be considered
where we start splitting up the monolithicly
administered network into various administrative
domains, and differently administered services.

	     Mike

---

From: Michael Thomas <[email-masked]>
Date: Sat, 19 Feb 2000 09:41:58 -0800 (PST)

> - normal boot image information for phones with downloadable code

   Dumb question: would a phone need its E.164 address(es)
   when registering, etc?

 > providing this is close to zero.

   Sure, but that wasn't my point of course.
 
 > assignments, any end system CPL, etc.

   This, however, was my point. If you believe in directories
   for configless widgets, it would make a lot more sense to
   dump all of this information there and have a pointer to
   the directory in DHCP. If the sum total of configuration 
   that a configurationless device is greater than just the
   address of the first hop proxy, then all this new
   option is doing is solving a small part of a previously 
   unsolved problem.

		Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 19 Feb 2000 13:07:04 -0500

>    Dumb question: would a phone need its E.164 address(es)

Actually, an interesting question. A phone would need the identity with
which it should register. From what I can tell, PBX will probably have
two identities for their phones, one "legacy" (E.164) identity and one
or more SIP identities (email address). It could be more than one if two
people share a phone, as our grad students do.

It might even have a third identity reflecting the phone's location,
e.g., "[email-masked]". The first two types of identities would
change if a person moved into a different office (assuming that she
leaves her phone behind), while the latter would stay constant.
Conversely, if people take their phones with them, only the last
identity would change.

Since these identities don't generally change all that often, this could
be hard-coded. (Fancier mechanisms, such as identities conveyed by
PalmPilots, have been discussed elsewhere.) Alternatively, a few of us
have discussed that there might well be a need for an additional
configuration parameter, namely a list of "identities" that the phone
should register with. Pretty straightforward to define, but I kind of
wanted to get the server issue out of the way first.

>    option is doing is solving a small part of a previously

Our current intent is to put some of this into the REGISTER response,
using an appropriate MIME type, since it avoids having to define yet
another directory protocol, more servers, etc. (Putting LDAP into an
embedded system strikes me as challenging, to put it mildly.)

However, the outbound proxy can be different from my registration
server.

Indeed, in order to find my non-multicast registration server, I need to
know my identity (see discussion above).

Thus, overall, I see DHCP used for things that are needed to bootstrap
into the SIP infrastructure with minimum cost and without creating
seventeen new directory servers. Almost all SOHO-style integrated
devices support DHCP, for obvious reasons, while installing and
configuring LDAP, say, seems like a stretch for this type of
application. (You don't mention a specific directory service, so pardon
me if I'm misinterpreting your remarks.)

Overall, the larger the number of servers, the higher the probability
that one of the alphabet soup servers is down, misconfigured. In my
view, it would be nice if I can install a basic Internet PBX with two
servers, a DHCP server and a SIP server. These seem to be required,
adding anything else as a basic requirement to make phones ring seems
like it needs a fair amount of justification for the complexity. This
does not mean that more complicated scenarios can't make good use of SLP
or LDAP. (We use LDAP in our SIP server and PC client, for example.)

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Dean Willis <[email-masked]>
Date: Wed, 23 Feb 2000 10:57:00 -0600

In actually doing this stuff, I can say that our experimental deployment
model is that the phone registers with an "identity" value which is
effectively unique to the phone. This "identity" is associated with users
(domain addresses) and phone numbers in a profile schema (directory). We
provide a web interface for managing the profile, or one can manipulate it
with SIP registrations. This allows users to forward their phones, move
them, clone them, sell them and buy new ones, etc.

The phone is not the user, nor is it the phone number. It's just a piece of
gear that may (or may not) be on the contact list for a given request URI as
that request URI evolves from the original request through processing by
proxies, etc.

--
Dean

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Henning
> Schulzrinne
> Sent: Saturday, February 19, 2000 12:07 PM
> To: Michael Thomas
> Cc: [email-masked]
> Subject: Re: DHCP option tags for SIP
>
>
> Michael Thomas wrote:
> >

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Feb 2000 02:57:54 -0500

> them, clone them, sell them and buy new ones, etc.

If I understand you right, the phone would have an ID, something like
sip:[email-masked]. When plugged in, it automatically registers
this address, binding it to its current IP address. In addition, users
can go to a web page (or use a SIP registration), and basically create
another binding, mapping their name (sip:[email-masked]) to the ID
of the phone (sip:[email-masked]). Is that right?

Neat idea... solves the problem that a standalone phone is not always
going to have an easy way for the user to enter their name that it
should use in a registration. It is basically adding another layer of
indirection: user->device->address, rather than just user->address.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 24 Feb 2000 09:33:55 -0500

> indirection: user->device->address, rather than just user->address.

There's an equivalent way of doing this, namely using the hardware ID
(aka MAC address). This also provides some level of authentication. One
possible problem of having a "back-channel" registration mechanism is to
make sure that the lifetimes of the registrations are lined up, so that
my user registration goes away if the low-level device registration goes
away. For that reason, I had suggested a configuration mapping where the
phone obtains a list of identities based on its hardware ID and
REGISTERs all of them. This also allows a web-based configuration
mechanism, but doesn't require anything special on the SIP server.

Either, I believe, can be made to work, depending on the assumptions as
to what's changeable, what's fixed and what's easier to integrate.

Beyond these details, I agree that we need to look at registration and
configuration more closely. We had separately discussed the "hotel
problem", for example.

A related problem, discussed earlier, is the current problem of
registrar crashes. In our local IP phone configuration, we have had the
problem of registrars crashing and then having to wait an hour until all
the registrations are back.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Dean Willis <[email-masked]>
Date: Thu, 24 Feb 2000 09:41:02 -0600

We thought about this, but didn't like it much given the way that our
experimental provisioning systems and UASes work. For example, my PC sip
client has nine different MAC addresses depending on where I'm sitting. Much
of the time it has two simultaneously, and sometimes it has three.  Also,
sometimes it is not the same physical device at all, but I want it to appear
to be (identity sharing), so there might be multiple sets of nine different
MAC addresses which are all "the same phone".

Given that the device identity (in the proposal, a MAC address) really has
to be distinctively inserted into the routing system, use of the MAC address
in this environment could get really messy.

We decided it was just easier to assign distinguished names to the devices,
and put only the distniguished name into the routing system.

Now, this might be very different in an environment where the UAS-of-choice
is a hardware phone that is persistent in its association with a singular
MAC address. I think Henning's approach has the potential to work quite well
here.

--
Dean

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Henning Schulzrinne
> Sent: Thursday, February 24, 2000 8:34 AM
> To: Jonathan Rosenberg
> Cc: Dean Willis; Michael Thomas; [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 24 Feb 2000 10:54:00 -0500

> MAC address. I think Henning's approach has the potential to work quite well

I agree that PCs and hardware phones have very different configuration
requirements. PCs typically already have all kinds of identifiers
available to them (CPU identifiers, GUIDs, OS license numbers, software
license numbers, user names, host names, etc.) and users can easily
create new ones via simple GUIs. On a hardware phone, installing a few
hundred phones and having the installer (or, worse, the phone's user)
key in some unique identifier for each is not very attractive. Having a
bar code on the bottom of the phone, reflecting its MAC address or, if
such a thing were available, some other globally unique identifier, is a
lot easier to manage. Columbia hands out hundreds of phones each year to
incoming freshmen, for example.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Richard Shockey <[email-masked]>
Date: Thu, 24 Feb 2000 10:04:39 -0600

>in this environment could get really messy.

I agree.

>and put only the distniguished name into the routing system.

I certainly think the distinguished name makes more sense in this 
environment. It also may be more useful in mobile environments.

Actually some of this looks like a "cell phone" network at a sufficient 
level of abstraction.

Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Francois Menard List Account <[email-masked]>
Date: Sat, 26 Feb 2000 15:18:03 -0500 (EST)

> indirection: user->device->address, rather than just user->address.

I've always maintained that there should be an easy way for a user
to log into a SIP phone before doing anything.  Ever since I heard that 
such a think has been tried out at 3COM, the thought of zapping my profile
using my Palm Pilot into a SIP phone with a SIR serial port remained
anchored in my brain.  I've always thought since that every
SIP phone should have an IR port for fast logons.

What comes with the profile is sometimes quite painful to enter manually,
when you think about it, a 2048bit PGP key isin't so easy to key in
either.

What I mean by this is that relying on MAC addresses as UUIDs and phone
numbers as authentification certificates has to stop at a point.  I do not
like the idea of resorting to multiple levels of indirection to circumvent
the problem of lack of enough information to begin with.  

-=Francois=-