Subject: [SIP] centralized vs. decentralized architectures

From: [email-masked]
Date: Wed, 4 Oct 2000 09:16:16 +0200

I have recently posed some questions about centralized vs. decentralized
architectures and SIP.

One issue is that there is no escape from requiring the user to register an
ID or to generate one. The need for user identity, as opposed to true
anonymity,  is one type of decentralization.

Another issue is that SIP-based systems often use distributed logic for
storing session state. On the other hand, the  "center" (the server) can
store session state using the back-to-back user-agent  design. In that
case, the server serves as a proxy in a sense (not the usual "SIP Proxy
Server sense" ) for the clients, communicating with them by another
protocol.

These seem to be part of the usual architecture for SIP-based systems. This
architecture puts the intelligence on the edge, not the center.

There are reasons for centralization of logic, such as
      (1) the typical benefits of a thin client
     (2) ACDs or other central decision-makers.

Nothing stops us from adopting a more centralized architecture with SIP,
even if it's unusual.

Joshua Fox
Senior Architect
Surf&Call Network Services

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: [email-masked]
Date: Thu, 5 Oct 2000 07:35:45 +0200

>Why doesn't a B2BUA provide true anonymity? By the way, I'm curious about
>why anonymity is so important: are there legitimate reasons for people to
>make calls anonymously?

When I mentioned "anonymity", I wasn't referring to the idea of keepingyour
human identity secret; I meant that for convenience, the user should not
have to provide a network identifier before making a call. There are indeed
legitimate reasons for people to make calls anonymously in this
sense--that's what we do when we call from a pay phone. Of course, a pay
phone has an E.164 number assigned to it--but what would you do if anyone
could instantly download and instantiate as many "pay phones" as they want?
There are various solutions to this problem: Require the user to register
an identifier (perhaps the most common solution), have the IP phone request
an identifier from a server, or generate an identifier randomly. Naturally,
unless the user registers, such a phone is only good for outgoing calls.

Joshua Fox

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 5 Oct 2000 16:26:26 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 05, 2000 1:36 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [SIP] centralized vs. decentralized architectures
> 
> 
> 
> 
> phone has an E.164 number assigned to it

And a sip payphone would have a sip URL assigned to it.

>--but what would you 
> do if anyone

How could they? Preumably network elements that provide service to this
payphone would authenticate it. If I assume such an identity in my SIP
client, I'd still need to authenticate myself, and I wouldn't be able to.

-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