Subject: RE: [SIP] Response if user not registered?

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 4 Apr 2001 02:03:23 -0400

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, April 02, 2001 6:22 AM
> To: Jonathan Rosenberg
> Cc: 'Roy, Radhika R, ALCOO'; Michael Thomas; [email-masked]
> Subject: Re: [SIP] Response if user not registered?
> 
> 
> Jonathan,
> 
> Good points.  However, moving this exended registration function
> outside of SIP reduces SIP to no better than a connection 
> establishment
> protocol which is ignorant of the service which is being provided
> by it.  In that case, why not move SIP's inbound registration function
> outside the protocol as well...

Well, to be honest, if I could do SIP over again from scratch, I would make
this a separate protocol. It more or less is, being an exception to a whole
bunch of rules as it stands now anyway.

That aside, I still find the process of assigning an S-CSCF at registration
to be a funny thing. I agree completely that you will ultimately want to
segment the servers in your domain, with users being assigned to a specific
server. THis segmentation is a common practice today, even, in email
systems. However, there, they make the segmentations algorithmic in nature.
I believe its common to assign users to mail servers based on the first
letter of their username. The algorithmic mappings are a lot easier to deal
with, and don't require any of these additional databases to hold the "user
to S-CSCF" mappings themselves.

Perhaps someone can clarify for me why it was decided to do it this way in
3gpp.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

> 
> --Brian
> 
> Jonathan Rosenberg wrote:                      (Mon, 02 Apr 
> 2001 04:07:49)
> >
> > I have to agree with Dean that this thread is awfully 
> confused and sometimes
> > frightening.
> > 
> > People want to charge for outgoing calls through proxies. 
> Whether I think
> > thats a good idea or not is irrelevant. To do that, these 
> people need to
> > identify the person or phone making the call. Thats OK. In 
> SIP, we have
> > mechanisms for allowing outbound proxies to authenticate 
> the caller, and
> > determine exactly who they are. Just dandy. I am totally 
> baffled as to what
> > this has to do with SIP registrations. SIP registrations 
> don't establish
> > identity, they don't upload authorizations, or anything 
> like that. They
> > create address bindings. Creating address bindings has 
> nothing to do with
> > making outbound calls.
> > 
> > I believe this issue in 3gpp arises because for them, they 
> have "extended"
> > register to do more than create bindings. They use it to 
> assign the proxy
> > which will handle both incoming and outgoing calls for the user, and
> > basically do not allow outgoing calls until such a 
> selection is made. So,
> > we're really not talking about registrations in the sip 
> sense. We are
> > talking about a new function. As the function is one of 
> policy, its also one
> > which, arguably, is an implementation decision, not a 
> protocol one. There is
> > no reason why I cannot build proxies that refuse outgoing 
> calls unless this
> > assignment function has taken place. Again, whether or not 
> this is a good
> > thing, is an entirely separate question.
> > 
> > -Jonathan R.
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
> _______________________________________________
> 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.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 04 Apr 2001 08:58:17 -0400

> bunch of rules as it stands now anyway.

Beyond addressing and Contact?

> to S-CSCF" mappings themselves.

The problem is that it is hard to convey the algorithmic mapping to
users. DHCP is specific to a device, not a user (and doesn't work for
remote configuration). So, you need *some* means of proxying
registrations based on registration identity. Since you want to be able
to change the number of servers without re-assigning users, doing this
dynamically is also helpful. Most email servers I know of (AOL being an
exception) just do randomized load balancing, with a common datastore
across all of them.

I agree with Jonathan that a database seems overkill. You want something
that is static and very fast, so that you don't run into scaling
problems on the lookup side. Since fine-grained allocation of users
makes no sense, I believe 3GPP (if it needs to specify this at all,
given that it's a local implementation issue), should just have a magic
mapping function, which can translate either into "twenty-six entry
in-memory table based on first letter of user name" or "triple-redundant
database running on a cluster of mainframes".

However, for redundancy, it is also not clear that having segregated
servers (by address or some fancy database) works well. You would have
to propagate registration information to all other servers in any event,
in which case you might as well have a single back-end database and a
bunch of randomly picked servers that handle the front-end processing.
One case might be if the subscriber transaction volume is too large for
a single database, so that you need a number of such clusters.