Subject: Re: SIP Spam Prevention (was Re: [Sip] calling number blocking at sip/isup ga...

From: [email-masked]
Date: Wed, 13 Feb 2002 09:59:41 EST

Dean,

Sorry it took me so long to reply. Hope the copy of previous e-mail exchange isn't confusing, since the way I am replying did not add carrots. I inserted who said it in [].

Thanks for the long, heart-felt response. No, I don't see your response as being "ranting" and I couldn't survive this type of work if I didn't keep a little humour with it. And I appreciate people who don't hold back on their ideas.

I think your comments, and your apparent view of what is important, emphasizes my main point that there are two different applications, or environments, in which SIP will be used to provide a telephony over IP capability. I represent an organization which is interested in using it in a large network to potentially replace the existing circuit-switched network (as standardized by ITU, etc.) You speak of an environment in which there is really no "telephony network", at least not in the traditional sense. Calls are set up from anywhere to anywhere ("arbitrary end-points") with no overall control by a "service provider". Yes, I agree that there is a place for such a non-network environment. But I am trying to address the other environment.

Also, there have been many opinions expressed that the desire is for the existing circuit-switched PSTN to be completely replaced with a packet-based network using SIP. I believe that, in order for this to happen, the current operation and requirements of the telephony network, including those mandated by state/federal laws, must be taken into account.

Yes, I realize that the IETF is not the ITU. (I'm at SG16 right now.) I believe that each organization has its advantages and disadvantages in its working procedures, but that is not the issue here. In the past, they dealt with competely different environments and networks. Now, both are trying to deal with the other's traditional network, and must take into account the realities of that other environment.

RFC 2804 is interesting reading, especially the part about how this policy (on not dealing with wire-tapping) was established. It says:

"Twenty-nine people spoke during the plenary session. ... Very few people spoke out strongly in support for adding the intercept features, while many spoke out against it, but a sizable portion of the audience refused to state an opinion (raised their hands when asked for "abstain" in the show of hands)."

Given the prevailing attitude in the IETF, can you image someone standing up in front of hundreds of participants and saying "I think this group should actively work on protocols to support wiretapping"? I can't. I wonder how many of those who didn't express an opinion represent companies whose official position is that they must support development of protocols for wire-tapping.

Anyway, I was not suggesting that the IETF should develop the protocols fpr this, only that other protocols developed should not make support of electronic surveillance impossible. Note that RFC 2804 says that the reasons for adopting this policy include: 

"the use of existing network features, if deployed intelligently, provides extensive opportunities for wiretapping, and should be sufficient under presently seen requirements for many cases."

and

"Correlating users' identities with their points of attachment to the Internet can be significantly harder, but not impossible, if the user uses standard means of identification. However, this means linking into multiple Internet subsystems used for address assignment, name resolution and so on; this is not trivial."

It seems to me that this reason for not addressing wire-tapping would no longer be true if SIP (and the network architecture) allows users to originate telephone calls with no identification. In fact, other required functions such as call tracing and maintenance also require the same, authenticated calling party identification capabilities.

(Incidentally, the IETF "policy" means little if the laws of the country mandate certain capabilities be supported as a criteria for providing service. Note Juha's e-mail of Jan 29.)

I understand your description of what happens if I try to set up a session to your SIP address and it's forwarded to your cell phone via the PSTN. But what you are doing doesn't constitute a "service provider" in the sense of what I am referring to. It's a simple call-forwarding function at the destination (of the IP portion). When you interwork to the PSTN to complete the call, then the PSTN's originating switch is the service provider and knows your identity (the ISDN line you use). Of course, it doesn't know or care about the identity of the first part of the call (the one to your SIP address). Yes, the bad guy may use such a service to make anonymous calls, but as soon as that is discovered, you, as the one who is providing the forwarding service could be required to support further identification of the original source of the call.

I agree that the verification between the end user and their "service provider" (SIP proxy) would use some "crypto" function. (I don't really call this "crypto" but rather a signing function.) Yes, in some environments VeriSign's certificate could be used, but other means exist depending on the nature of the local network. It's between the end party and their service provider. The point I'm making is that in the world-wide telephony network, the ability to believe that the calling party number delivered at the destination is legitimate should not involve such a crypto or signing function between the called party and the originating party or some agent representing the originating party. I have a hard time believing that this can occur in the time required for call set up.

Your example of doing stock trades with Schwab is not one of using the calling party ID that we have been discussing. It presumes that some previous business relationship exists between you and Schwab, including the establishment of a shared secret. They don't care that the call was made from your phone, they want to know it's really you, no mater what phone you're using. On the other hand, the calling party identification we're talking about must be between any two phones in the network (the whole world?).

I don't open e-mail if I don't recognize the "from" or the subject. I accepted and opened your e-mail based on some level of trust that what came to me had a legitimate "from" address. Yes, I realize that the e-mail you sent me could have been faked and really be from someone else. I want a telephony network in which the called party can trust the calling party ID delivered to them (because they trust their own proxy or "service provider").

In a message dated 2/1/02 8:34:45 PM Eastern Standard Time, [email-masked] writes:

Warning! This response contains philosophical ranting. Please take a large
dose of humour supplement to help ease the pain.

----- Original Message -----
From: <[email-masked]>
> Dean mumbled:
> > Ah. In the case I referenced, there WAS no service provider originating the
> > call. It was produced by a SIP UA on the Internet. From that point of view,
> > every PC is a service provider . . .
>

[Mike]
> Interesting, but this points out the basic difference in network
> architectures that we are addressing. You talk as if the telephone call
> originates out of nowhere, like some Spam seems to today. I am talking of a
> network architecture view in which every telephone call must begin and end
> under control of a "service provider". (And that doesn't mean a provider with
> a physical netwok like today's telephone companies.) In this network
> architecture, all the privacy issues (calling party ID, called party ID,
> names, etc.) are dealt with by the choosen service provider. (You don't get
> service from someone you don't trust, nor do they provide service to someone
> if they don't have a way to verify who is trying to originate a call.) And at
> the same time, the legal invasions of privacy, to support wire-tapping, would
> be dealt with by this same service provider.

[Dean]
I believe you have us confused with the ITU ;-) . .

Mike, this is the INTERNET Engineering Task Force. We're concerned with the
Internet -- it's a big packet-switching thing that allows arbitrary
communications between arbitrary endpoints. Being a "Service Provider"
fundamentally means to take packets from a customer, insert them into the
switching fabric, and swish them on their merry way -- or, to take packets
from the switching fabric as appropriate and hand them to your customer. Of
course, there can be higher-level service providers. VeriSign is a good
example of a service provider who provides tools to cope with the issues you
raise, without being "Big Brother" and controlling everybody. I should give
my speech on the difference between "control" and "service" for you someday
 . .

As for the rest, please see RFC 2804 for the IETF policy on wiretapping and
RFC 1984 for the general policy on crypto. Good recreational reads, right up
there with the Magna Carta and the Declaration of Independence, which are
also probably useful reads for someone with too much background in
tradtional telephony.

[Mike]
> Yes, someone could agree to handle originations of telephone calls from
> unknown parties, but I can't imagine these calls ever being allowed to
> interwork into the PSTN or into a comercial IP-based telephony service
> provider's network. And laws on electronic surveillance will eventually
> forbid it anyway.

[Dean]
Try setting up a session to sip:[email-masked]. If I'm not sitting
at my desk, said call will be interworked into the PSTN and delivered to my
cell phone. Right now, and every day for the past year and a half, except
when the phone company broke the ISDN lines for a while. I suppose it could
be spammed in a denial-of-service attack, but the last guy to do that is
still suffering. Of course, you just just call my cell phone directly from
outside the US with the same effect. On the other hand, we are working on
triocks to verify that the request you've sent really came from the IP
address that's claiming to send it, and barring the Zombie Attacks
engendered by flawed Redmondian security systems will probably be adequate
for my purposes.

[Mike]
> > > What bothers me is that we are modeling this on current stuff, and yesterday
> > > I got two copies of the new "Party" virus attached to e-mails from
> > > "UnknownSender". If we can't stop this in e-mail today, what is the future
> > > telephony network going to be like?

> > [Dean]
> > Absoultely correct. This is why I want cryptographic support for the PID
> > header, and transitive vouching techniques thereon. If you get a call whose
> > RPID can't be verified, it becomes perfectly legitimate to do something
> > nasty to it like forward it to a robot that explains your policy about
> > anonymmous calls. Or, you can listen if you want -- some people LIKE to live
> > dangerously.
>

[Mike]
> Again, in the network architecture I'm referring to, cryptographic procedures
> are not the answer to privacy for calling party ID. Yes, such procedures may
> be used by the originating service provider to verify that the calling party
> is legitimate, and by the terminating party to determine that the call
> attempt comes from their choosen service provider, then these procedures do
> not need to be applied to the calling party ID iteself. In an enterprise
> network, we may use cryptographic measures between parties in that closed
> set, but for the general telephony environment, the end user who receives a
> call shouldn't be required to apply cryptographic procedures with the
> originator to verify contents of the call setup message.

[Dean]
You have to do the crypto, either with the originator or with a trusted
intermediary who vouches for the originator. Sounds like a service provider
opportunity to me. What you're proposing is not really different than the
fundamental PKI model -- it's just a question of who does the crypto, and
since your "phone" is going to have to do crypto just to recognize the
service provider, there's not much of a difference in the scope of the
problem. It's all just a big "proxy" business.

For example, let's say I want to trade some stocks. I fire up my browser and
point it at Schwab. How do I know that it's really the Schwab site
responding, and not my ex-wife's attorney trying to figure out where I hid
my last 37 cents? Well, Schwab has a cert. It was signed by VeriSign. Thru
other channels, I got a copy of VeriSign's cert (Chairman Bill was kind
enough to include it with the OS on my office PC, and some guys in Red Hats
packaged it up for my house). I use VeriSign's cert to check that my
connection with Schwab was signed with Schwab's cert. Transitive trust,
right? So why don't we use this approach for everything? Simple, really --
people are too cheap to pay for their own cert, too lazy to deal with it, or
to ignorant to care (I suffer from all three). Or they just don't trust Big
Guys, and would rather weave their own web of transitive trust with
something like PGP, which also tends to run afoul of the "lazy" and
"ignorant" set. And very occasionally because the device involved is just a
little too small to run the crypto (the threshold is a code size somwhere
around 64kB).

 . . much elided . . .

[Mike]
> Concerning your comment above that the call may start at any SIP UA on the
> Internet (someone's PC). I firmly believe that it will eventually be admitted
> that the issues of verification, privacy, service provisioning, accounting,
> wiretap, etc. require that every "end user" of SIP have a dedicated SIP proxy
> to handle originating and terminating calls. This UA-SIP proxy relationship
> must be established when the device is turned on, makes the first call, etc.
> Thereafter, all interactions for individual phone calls are between this
> trusted SIP proxy and the end-user (SIP UA). The SIP Proxy is then the
> service provider (and responsible for all the above functions). I believe
> this architecture is beginning to be recognized as required for various
> purposes and we can't move forward until it is accepted for all cases.

[Dean]
Wow. I really hope you're completely wrong in the general case, otherwise
I've wasted most of the last twenty years working on the Internet.
Especially since I'm my own service provider and run my own proxy and my own
PSTN interconnects. I also run my own web server and my own email exchanger
and do all sorts of other stuff you would probably expect to reserve for
"service providers". Hey, you better reject this email, because it just came
from an Unknown Source! Yep, I use service providers, but I choose to do so
at a different level than you're proposing, and that's OK, because this is
the Internet, not a government-sponsored work camp for the political
re-education of people who have expressed libertarian sympathies in a public
forum.

On the other hand, there IS substance in much of what you're saying. It's
just that we hope to offer solutions that don't require fixed "wires", or
the virtual equivalent thereof, between the slaves and the masters. In fact,
I think most of the community would happily do without the "slaves" and the
"masters" as well.

And it now being Friday evening, I'm going to go work from the other desk.
Good night.

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 13 Feb 2002 12:26:46 -0600

>I believe that, in order for this to happen, the current operation
>requirements of the telephony network, including those mandated by 
>state/federal laws, must be taken into account.

This is a serious statement that we always have to keep in mind, though
the right way:

1 - IP communications on the Internet does on no way need to replicate
the existing telephone network, with all its limitations, for many good
reasons, not the least because so many new services are possible on the
Internet.

2 - State/federal laws regarding the Internet are still under
development, and as can be noticed, may be very different than those
applying for the telephone network.

Henry 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Wednesday, February 13, 2002 9:00 AM
> To: [email-masked]; [email-masked]
> Subject: Re: SIP Spam Prevention (was Re: [Sip] calling 
> number blocking at sip/isup ga...
> 
> 
> Dean,
> 
> Sorry it took me so long to reply. Hope the copy of previous
> e-mail exchange isn't confusing, since the way I am replying 
> did not add carrots. I inserted who said it in [].
> 
> Thanks for the long, heart-felt response. No, I don't see
> your response as being "ranting" and I couldn't survive this 
> type of work if I didn't keep a little humour with it. And I 
> appreciate people who don't hold back on their ideas.
> 
> I think your comments, and your apparent view of what is
> important, emphasizes my main point that there are two 
> different applications, or environments, in which SIP will be 
> used to provide a telephony over IP capability. I represent 
> an organization which is interested in using it in a large 
> network to potentially replace the existing circuit-switched 
> network (as standardized by ITU, etc.) You speak of an 
> environment in which there is really no "telephony network", 
> at least not in the traditional sense. Calls are set up from 
> anywhere to anywhere ("arbitrary end-points") with no overall 
> control by a "service provider". Yes, I agree that there is a 
> place for such a non-network environment. But I am trying to 
> address the other environment.
> 
> Also, there have been many opinions expressed that the desire
> is for the existing circuit-switched PSTN to be completely 
> replaced with a packet-based network using SIP. I believe 
> that, in order for this to happen, the current operation and 
> requirements of the telephony network, including those 
> mandated by state/federal laws, must be taken into account.
> 
> Yes, I realize that the IETF is not the ITU. (I'm at SG16
> right now.) I believe that each organization has its 
> advantages and disadvantages in its working procedures, but 
> that is not the issue here. In the past, they dealt with 
> competely different environments and networks. Now, both are 
> trying to deal with the other's traditional network, and must 
> take into account the realities of that other environment.
> 
> RFC 2804 is interesting reading, especially the part about
> how this policy (on not dealing with wire-tapping) was 
> established. It says:
> 
> "Twenty-nine people spoke during the plenary session. ...
> Very few people spoke out strongly in support for adding the 
> intercept features, while many spoke out against it, but a 
> sizable portion of the audience refused to state an opinion 
> (raised their hands when asked for "abstain" in the show of hands)."
> 
> Given the prevailing attitude in the IETF, can you image
> someone standing up in front of hundreds of participants and 
> saying "I think this group should actively work on protocols 
> to support wiretapping"? I can't. I wonder how many of those 
> who didn't express an opinion represent companies whose 
> official position is that they must support development of 
> protocols for wire-tapping.
> 
> Anyway, I was not suggesting that the IETF should develop the
> protocols fpr this, only that other protocols developed 
> should not make support of electronic surveillance 
> impossible. Note that RFC 2804 says that the reasons for 
> adopting this policy include: 
> 
> "the use of existing network features, if deployed
> intelligently, provides extensive opportunities for 
> wiretapping, and should be sufficient under presently seen 
> requirements for many cases."
> 
> and
> 
> "Correlating users' identities with their points of
> attachment to the Internet can be significantly harder, but 
> not impossible, if the user uses standard means of 
> identification. However, this means linking into multiple 
> Internet subsystems used for address assignment, name 
> resolution and so on; this is not trivial."
> 
> It seems to me that this reason for not addressing
> wire-tapping would no longer be true if SIP (and the network 
> architecture) allows users to originate telephone calls with 
> no identification. In fact, other required functions such as 
> call tracing and maintenance also require the same, 
> authenticated calling party identification capabilities.
> 
> (Incidentally, the IETF "policy" means little if the laws of
> the country mandate certain capabilities be supported as a 
> criteria for providing service. Note Juha's e-mail of Jan 29.)
> 
> I understand your description of what happens if I try to set
> up a session to your SIP address and it's forwarded to your 
> cell phone via the PSTN. But what you are doing doesn't 
> constitute a "service provider" in the sense of what I am 
> referring to. It's a simple call-forwarding function at the 
> destination (of the IP portion). When you interwork to the 
> PSTN to complete the call, then the PSTN's originating switch 
> is the service provider and knows your identity (the ISDN 
> line you use). Of course, it doesn't know or care about the 
> identity of the first part of the call (the one to your SIP 
> address). Yes, the bad guy may use such a service to make 
> anonymous calls, but as soon as that is discovered, you, as 
> the one who is providing the forwarding service could be 
> required to support further identification of the original 
> source of the call.
> 
> I agree that the verification between the end user and their
> "service provider" (SIP proxy) would use some "crypto" 
> function. (I don't really call this "crypto" but rather a 
> signing function.) Yes, in some environments VeriSign's 
> certificate could be used, but other means exist depending on 
> the nature of the local network. It's between the end party 
> and their service provider. The point I'm making is that in 
> the world-wide telephony network, the ability to believe that 
> the calling party number delivered at the destination is 
> legitimate should not involve such a crypto or signing 
> function between the called party and the originating party 
> or some agent representing the originating party. I have a 
> hard time believing that this can occur in the time required 
> for call set up.
> 
> Your example of doing stock trades with Schwab is not one of
> using the calling party ID that we have been discussing. It 
> presumes that some previous business relationship exists 
> between you and Schwab, including the establishment of a 
> shared secret. They don't care that the call was made from 
> your phone, they want to know it's really you, no mater what 
> phone you're using. On the other hand, the calling party 
> identification we're talking about must be between any two 
> phones in the network (the whole world?).
> 
> I don't open e-mail if I don't recognize the "from" or the
> subject. I accepted and opened your e-mail based on some 
> level of trust that what came to me had a legitimate "from" 
> address. Yes, I realize that the e-mail you sent me could 
> have been faked and really be from someone else. I want a 
> telephony network in which the called party can trust the 
> calling party ID delivered to them (because they trust their 
> own proxy or "service provider").
> 
> 
> Warning! This response contains philosophical ranting. Please
> take a large dose of humour supplement to help ease the pain.
> 
> > > Ah. In the case I referenced, there WAS no service provider
> > > originating the call. It was produced by a SIP UA on the 
> Internet.
> > > From that point of view, every PC is a service provider . . .
> >
> 
> 
> [Mike]
> > architectures that we are addressing. You talk as if the telephone 
> > call originates out of nowhere, like some Spam seems to today. I am 
> > talking of a network architecture view in which every 
> telephone call
> > must begin and end under control of a "service provider". (And that
> > doesn't mean a provider with a physical netwok like today's 
> telephone
> > companies.) In this network architecture, all the privacy issues
> > (calling party ID, called party ID, names, etc.) are dealt 
> with by the
> > choosen service provider. (You don't get service from someone you
> > don't trust, nor do they provide service to someone if they 
> don't have
> > a way to verify who is trying to originate a call.) And at the same
> > time, the legal invasions of privacy, to support 
> wire-tapping, would
> Mike, this is the INTERNET Engineering Task Force. We're
> concerned with the Internet -- it's a big packet-switching 
> thing that allows arbitrary communications between arbitrary 
> endpoints. Being a "Service Provider" fundamentally means to 
> take packets from a customer, insert them into the switching 
> fabric, and swish them on their merry way -- or, to take 
> packets from the switching fabric as appropriate and hand 
> them to your customer. Of course, there can be higher-level 
> service providers. VeriSign is a good example of a service 
> provider who provides tools to cope with the issues you 
> raise, without being "Big Brother" and controlling everybody. 
> I should give my speech on the difference between "control" 
> and "service" for you someday  . .
> 
> As for the rest, please see RFC 2804 for the IETF policy on
> wiretapping and RFC 1984 for the general policy on crypto. 
> Good recreational reads, right up there with the Magna Carta 
> and the Declaration of Independence, which are also probably 
> useful reads for someone with too much background in 
> tradtional telephony.
> 
> 
> [Mike]
> > Yes, someone could agree to handle originations of telephone calls
> > from unknown parties, but I can't imagine these calls ever being 
> > allowed to interwork into the PSTN or into a comercial IP-based 
> > telephony service provider's network. And laws on electronic 
> > surveillance will eventually forbid it anyway.
> 
> 
> [Dean]
> Try setting up a session to sip:[email-masked]. If
> I'm not sitting at my desk, said call will be interworked 
> into the PSTN and delivered to my cell phone. Right now, and 
> every day for the past year and a half, except when the phone 
> company broke the ISDN lines for a while. I suppose it could 
> be spammed in a denial-of-service attack, but the last guy to 
> do that is still suffering. Of course, you just just call my 
> cell phone directly from outside the US with the same effect. 
> On the other hand, we are working on triocks to verify that 
> the request you've sent really came from the IP address 
> that's claiming to send it, and barring the Zombie Attacks 
> engendered by flawed Redmondian security systems will 
> probably be adequate for my purposes.
> 
> [Mike]
> > > > What bothers me is that we are modeling this on current
> stuff, and
> > > > yesterday I got two copies of the new "Party" virus attached to
> > > > e-mails from "UnknownSender". If we can't stop this in e-mail 
> > > > today, what is the future telephony network going to be like?
> 
> 
> > > [Dean]
> > > Absoultely correct. This is why I want cryptographic
> support for the
> > > PID header, and transitive vouching techniques thereon.
> If you get a
> > > call whose RPID can't be verified, it becomes perfectly
> legitimate
> > > to do something nasty to it like forward it to a robot
> that explains
> > > your policy about anonymmous calls. Or, you can listen if
> you want
> > > -- some people LIKE to live dangerously.
> >
> 
> 
> [Mike]
> > Again, in the network architecture I'm referring to, cryptographic
> > procedures are not the answer to privacy for calling party ID. Yes, 
> > such procedures may be used by the originating service provider to 
> > verify that the calling party is legitimate, and by the terminating 
> > party to determine that the call attempt comes from their choosen 
> > service provider, then these procedures do not need to be 
> applied to
> > the calling party ID iteself. In an enterprise network, we may use
> > cryptographic measures between parties in that closed set, 
> but for the
> > general telephony environment, the end user who receives a call
> > shouldn't be required to apply cryptographic procedures with the 
> You have to do the crypto, either with the originator or with
> a trusted intermediary who vouches for the originator. Sounds 
> like a service provider opportunity to me. What you're 
> proposing is not really different than the fundamental PKI 
> model -- it's just a question of who does the crypto, and 
> since your "phone" is going to have to do crypto just to 
> recognize the service provider, there's not much of a 
> difference in the scope of the problem. It's all just a big 
> "proxy" business.
> 
> For example, let's say I want to trade some stocks. I fire up
> my browser and point it at Schwab. How do I know that it's 
> really the Schwab site responding, and not my ex-wife's 
> attorney trying to figure out where I hid my last 37 cents? 
> Well, Schwab has a cert. It was signed by VeriSign. Thru 
> other channels, I got a copy of VeriSign's cert (Chairman 
> Bill was kind enough to include it with the OS on my office 
> PC, and some guys in Red Hats packaged it up for my house). I 
> use VeriSign's cert to check that my connection with Schwab 
> was signed with Schwab's cert. Transitive trust, right? So 
> why don't we use this approach for everything? Simple, really 
> -- people are too cheap to pay for their own cert, too lazy 
> to deal with it, or to ignorant to care (I suffer from all 
> three). Or they just don't trust Big Guys, and would rather 
> weave their own web of transitive trust with something like 
> PGP, which also tends to run afoul of the "lazy" and 
> "ignorant" set. And very occasionally because the device 
> involved is just a little too small to run the crypto (the 
> threshold is a code size somwhere around 64kB).
> 
>  . . much elided . . .
> 
> 
> [Mike]
> > Concerning your comment above that the call may start at
> any SIP UA on
> > the Internet (someone's PC). I firmly believe that it will
> eventually
> > be admitted that the issues of verification, privacy, service
> > provisioning, accounting, wiretap, etc. require that every 
> "end user"
> > of SIP have a dedicated SIP proxy to handle originating and
> > terminating calls. This UA-SIP proxy relationship must be 
> established
> > when the device is turned on, makes the first call, etc.
> Thereafter,
> > all interactions for individual phone calls are between
> this trusted
> > SIP proxy and the end-user (SIP UA). The SIP Proxy is then
> the service
> > provider (and responsible for all the above functions). I
> believe this
> > architecture is beginning to be recognized as required for various
> Wow. I really hope you're completely wrong in the general
> case, otherwise I've wasted most of the last twenty years 
> working on the Internet. Especially since I'm my own service 
> provider and run my own proxy and my own PSTN interconnects. 
> I also run my own web server and my own email exchanger and 
> do all sorts of other stuff you would probably expect to 
> reserve for "service providers". Hey, you better reject this 
> email, because it just came from an Unknown Source! Yep, I 
> use service providers, but I choose to do so at a different 
> level than you're proposing, and that's OK, because this is 
> the Internet, not a government-sponsored work camp for the 
> political re-education of people who have expressed 
> libertarian sympathies in a public forum.
> 
> On the other hand, there IS substance in much of what you're
> saying. It's just that we hope to offer solutions that don't 
> require fixed "wires", or the virtual equivalent thereof, 
> between the slaves and the masters. In fact, I think most of 
> the community would happily do without the "slaves" and the 
> "masters" as well.
> 
> And it now being Friday evening, I'm going to go work from
> the other desk. Good night.
> 
> --
> Dean
> 
> 
> 
> 
> Use [email-masked] for questions on current
> sip Use [email-masked] for new developments on the 
> application of sip
>