Subject: RE: [SIP] The Endless User-Network-Registration Debate Seems Mostly Bogus

From: Henry Sinnreich <[email-masked]>
Date: Sun, 01 Apr 2001 18:51:22 -0500

Dean Willis wrote:
>maybe my phone should send a REGISTER for every phone number and
>every user name I go by (currently a list of over 50 identities)

I believe the Microsoft Wallet (just emerging in the trade press) does also
something like this, except it identifies the user to each server
separately, when logging on.

Henry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Dean Willis
Sent: Saturday, March 31, 2001 6:36 PM
To: IETF SIP (E-mail)
Subject: [SIP] The Endless User-Network-Registration Debate Seems Mostly
Bogus

ok, time for a soap-box speech. . . .

We've been going around on whether networks can deregister phones and what
the impact of a user who hasn't registered may be and whether it's the
terminal or the user that is registering.

I really don't think I understand this whole argument. That' or the argument
is happening between people who just don't understand SIP.

When I turn on the SIP phone on my desk, it sends register messages to three
different registrars.

Optionally, each registration could be authenticated with separate
credentials. None of those credentials has anything whatsover to do with
authorizing my phone to talk to the network. Getting permission to talk to
the network happened when my phone used DHCP to get an address assignment
from a server . . .

And NONE of those registrations have anything whatsoever to do with whether
that phone can make a call. They influence only INBOUND calls to the
identities associated with the registrations.

Whether or not the phone has registered HAS ABSOLULTELY NO IMPACT on whether
that phone has "access" to the network. In fact, it has to have access to
the network BEFORE it can register. Registration is an application, not an
access control mechanism.

I think we're getting layers 2, 3, and 4 horribly confused.

Now let's think about a concept I call an "identity" and that I believe the
kerberos people call a "principal".

An identity is essentially a distinguished name. Generally, credentials
exist which allow the holder of those credentials to be authenticated as the
"identity" in question.

A user can have an identity.
A phone can have an identity.
My dog can have an identity.

REGISTER is a mechanism by which the holder of an identity says "HERE I AM:
SEND PACKETS HERE TO REACH THIS IDENTITY". We might call that a dynamic
binding.

DNS and the various phone-route mechanisms provide a relatively static
binding between an idenity (or classes of identities) and SIP proxies. For
example: for all calls whose target identities have a domain poart of
"dynamicsoft.com", please consult this proxy when resolving the call.

SIP allows programmatic routing of calls, which may involve changing the
identity to which the call is destined. When combined with REGISTER, we're
using a static binding to get the call to a location at which a dynamic
binding can be applied, a palce I call a "binding point" or "identity
server".

For example, sometimes there's a REGISTER application on my home PC that
talks to my office proxy. But my home PC doesn't receive SIP calls. This
application uses REGISTER to tell the proxy "calls to
[email-masked] need to be remapped to the identity 9725199190
in your scope", which sends the calls out through a gateway to the PSTN.

And if I stop stroking my home PC, it stops sending REGISTER messages, the
registration expires, and my phone calls stop following me home and they go
someplace else -- to an identity that DOESN'T send REGISTER messages,
because it's a destination statically configured in the CPL attached to my
profile in that proxy at the office.

3G efforts may wish to layer the user's identity on top of the phone's
identity. For example, a phone, when actuated, might REGISTER with its home
proxy or with some other proxy whose address is learned outside of SIP. The
user identity's profile might wish to include logic (which could be CPL)
that says "check to see if my phone is registered, and if so send the call
there and if not send it to voice mail. The user's identity server (a
REGISTRAR) might wish to SUBCRIBE to the registration state of the phone
(provided by the phone's REGISTRAR, not the phone) in order to proactively
start sending calls somewhere else if the phone deregisters. Or, if the
phone's registrar and the user's registrar happen to be the same registrar,
local application logic might be used to do the same thing (I do have an app
that works that way). Or they could use a common lower-layer database
replication to achieve the same effect. But I can do all this without having
to change SIP or make it act in any way more SS7-like. It's an
IMPLEMENTATION DECISION, not a PROTOCOL DEFINITION.

But hey, maybe my phone should send a REGISTER for every phone number and
every user name I go by (currently a list of over 50 identities) to each of
the different identity servers (50 or so, scattered across the face of this
planet) associated with those identities. That's a legitimate SIP usage, AND
I HOPE YOU BELLHEADS (Sorry, Bob!) DON'T MESS THIS UP because I think it's a
pretty cool application. And its rather completely unlike the way phones,
mobile phones, or SS7, or IS-41, or GSM, etc. work today.

And by the way, it shouldn't matter whether my phone has a UMTS or 802.11B
or 100-base-T connection, because the application is just ordinary SIP
running over ordinary IP.

Thanks for listening.

--
Dean

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to
[email-masked] with "subscribe" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.