Subject: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 1 Apr 2007 09:59:22 -0700

Paul,

> I more or less agree with the final conclusion below.

This is good starting point to discuss some usage scenarios.

Putting on my former hat as an employee for a carrier, I cannot overlook
the following:

P2P SIP implemented correctly in the residential access box or cable
set-top box indeed is a good or better replacement for the entire VoIP
network infrastructure (cost, operations, new services, etc). 
Integrated access devices for the enterprise can probably play a similar
role, not to mention existing P2P PBX products (please refer to all the
advantages of P2P that need not repeated here).

What do people think of these three usage scenarios for P2P SIP:
- SIP peer in the DSL access device,
- SIP peer in the cable access device,
- SIP peer in enterprise network integrated access device (IAD).

Note that these examples imply very low churn for the peers and add the
data retention resilience of P2P (geographic diversity is native and
mobile, etc.). Incidentally, NAT traversal may also not be a problem, or
at least an easier problem.

What do you all think?

I have taken the liberty to copy the P2P SIP list, since the low churn
scenarios are of interest for the DHT selection. Or just pick the same
DHT for all scenarios anyway? I don't think so.

Thanks, Henry

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, March 30, 2007 6:31 PM
To: Eunsoo Shim
Cc: Henry Sinnreich; Michael Hammer (mhammer); David R Oran;
[email-masked]; [email-masked]; zhuxian
Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario

I more or less agree with the final conclusion below.

My main point here is that P2P and C/S need not be enemies. Nor is a 
total C/S system necessarily evil. What is most evil is *bundling* of 
services that prevents freedom of choice.

I think I would be quite happy with a SP that provides a registrar/proxy

and allows me to provide all other features as I see fit - by taking 
them ala carte from the SP, or subscribing to them from one or more 
other SPs, or by providing them myself via appliances I own. If that 
registrar/proxy was replaced by a P2P sip community, the differences, if

any, would hopefully be more a function of the implementation and the 
business models of those involved than the architecture.

(I gather the general assumption is that a P2P setup will be *free*. But

I have a hard time believing that. If most of the usage is by mobile 
devices that can't be peers, then somebody will have to pay for enough 
peers to support them. If it isn't free, then how is it better than a 
well engineered C/S system?)

So I think the key thing here is that some features will require getting

some help from another node. There ought to be the option to pick a 
different source for each helper you require, and an ability for it all 
to play together.

	Paul

Eunsoo Shim wrote:
> Please see my inline comment.
> 
> On 3/30/07, *Paul Kyzivat* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     Henry Sinnreich wrote:
>      > David Oran wrote (with regard to voice mail):
>      >
>      >> I'm not saying this can't be made to work, only that it isn't
>      > immediately >obvious that it has advantages over a classic
>     application
>      > server >approach.
>      >
>      > The answer for VM is "it depends":
>      >
> 
> 
> I agree. It really depends. Certainly there are tradeoffs.
> 
>      > There are several commercial P2P IP PBX solutions without any
>     server for
>      > VM or anything else. No doubt the IT organization appreciates
just
>      > having to plug in the IP phones and GWY to the PSTN without any
>      > configuration ever for VM or any other PBX feature.
> 
>     I don't understand. Are you saying they don't have VM, or that
they
>     don't have a *server* for VM?
> 
> 
> I guess they don't have a  *server* for  VM.
> 
>      > For public P2P SIP networks there are two more scenarios where
VM can
>      > reside (and without ever spending one cent on VM servers + IT
>     systems):
>      >
>      > - In Cable and DSL service provider networks: The residential
>     router can
>      > act as a voice recorder
> 
>     That is simply an example of the user having an appliance of his
own
>     that provides VM service.
> 
>      > and P2P can cover the not too frequent cases,
>      > where the router is not in operation, so the data is backed up
in
>     other
>      > peer residential gateways (encrypted).
> 
>     I guess I just need to have more info about how this would work
before I
>     will be convinced it is feasible and trustworthy.
> 
> 
> Well, 'trustworthy' could be  considered in many angles.
> If it is about privacy of the message, a public key based encryption 
> would provide acceptable privacy.
> If it is about reliability of the message delivery, well, a P2P based 
> asynchronous message delivery (like VM) is most likely less reliable 
> than a well managed server based system.
> However, my experience with Skype's asynchronous message delivery was 
> not bad. Actually I don't see any significant difference between it
and 
> my cellular service provider's VM service. :-)
> Reliability is always a challenge for P2P, for sure. But, I believe it

> is feasible to build a P2P system for VM acceptable for many
scenarios.
> 
>      > - In mobile networks: The VM can reside in quite stable peers
>     inside the
>      > wireless base station network. The peers in the base station
network
>      > need no configuration, etc.
> 
>     I don't understand. I guess that could be true if the peers are
willing
>     to store an arbitrary amount of VM indefinitely for anybody. Is
that
>     believable?
> 
> 
> It depends.
> In a very nice environment where all the peers are willing to
cooperate 
> at their best, the peers will store as much as they can. In a tough 
> environment, the situation will be different.
> 
>     This seems to translate to a model where it is assumed that those
nodes
>     that are on most of the time will be willing to provide VM storage
for
>     those nodes that aren't on most of the time.
> 
> 
> This is again related to reliability of P2P systems or topics like
free 
> riders and reputation.
> A P2P system is a community or society. To be simple, if many of the 
> members are bad, the community won't work well. If the majority of the

> members are good, the community will work well or reasonably.
> 
>      > Add to this the conferencing capability coming from p2p
application
>      > layer multicast, the SIP e2e control capabilities (for such as
>      > auto-attendant, agent workstation, etc.) and one has to wonder
why IT
>      > networks, public VoIP networks and end users should support the
huge
>      > cost of hand engineering, testing, monitoring, maintaining
server
>     based
>      > VoIP networks. P2P self configuration is nothing less that
automation
>      > applied to VoIP, plus the shifting of computing to the
endpoints,
>     where
>      > there is an abundance of unused CPU, storage, bandwidth and
>     electricity.
>      >
>      > Eric Burger also notes IM changes completely the usage for VM
and may
>      > make unnecessary to place calls on VM in the first place.
> 
>     I find this more promising.
> 
>           
> 
> 
> In overall, are we discussing if P2P systems based VM can work? I
think 
> it can work.  Just it depends on many things.
> If it is not super-reliable, should we disregard it? I would say no.
> 
> On the other hand, do we have to abandon client server based VM and 
> switch to P2P system based VM? It is upto each of us.
> Client server based VM systems are already there.
> So why don't we work on P2P based VM now?
>  
> Thanks.
> 
> Eunsoo

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 1 Apr 2007 20:47:28 +0200

Henry,

Aren't you confusing "usage scenarios" with "deployment scenarios" here? Why 
restrict P2P SIP to only certain types of devices? And if you insist on 
that, why not mobile devices?

Regards,
Jeroen

Henry Sinnreich wrote:
> Putting on my former hat as an employee for a carrier, I cannot
> overlook the following:
>
> Integrated access devices for the enterprise can probably play a
> similar role, not to mention existing P2P PBX products (please refer
> to all the advantages of P2P that need not repeated here).
>
> Note that these examples imply very low churn for the peers and add
> the data retention resilience of P2P (geographic diversity is native
> and mobile, etc.). Incidentally, NAT traversal may also not be a
> problem, or at least an easier problem.
>
> What do you all think?
>
> different source for each helper you require, and an ability for it
> all to play together.
>
> Paul
>
> Eunsoo Shim wrote:
>>      just > having to plug in the IP phones and GWY to the PSTN
>>      without any > configuration ever for VM or any other PBX
>> feature.
>>
>>     they don't have a *server* for VM?
>>
>>
>>      > For public P2P SIP networks there are two more scenarios
>>      where VM can > reside (and without ever spending one cent on VM
>>     servers + IT systems):
>>      >
>>     own that provides VM service.
>>
>>      > where the router is not in operation, so the data is backed
>>     up in other
>>     before I will be convinced it is feasible and trustworthy.
>>
>>
>> and my cellular service provider's VM service. :-)
>>      network > need no configuration, etc.
>>
>>     willing to store an arbitrary amount of VM indefinitely for
>>     anybody. Is that believable?
>>
>>
>> It depends.
>> cooperate at their best, the peers will store as much as they can.
>> In a tough environment, the situation will be different.
>>
>>     This seems to translate to a model where it is assumed that
>>     those nodes that are on most of the time will be willing to
>>     provide VM storage for those nodes that aren't on most of the
>> time.
>>
>>
>> free riders and reputation.
>>      application > layer multicast, the SIP e2e control capabilities
>>      (for such as > auto-attendant, agent workstation, etc.) and one
>>      has to wonder why IT > networks, public VoIP networks and end
>>      users should support the huge > cost of hand engineering,
>>     testing, monitoring, maintaining server based
>>      automation > applied to VoIP, plus the shifting of computing to
>>     the endpoints, where
>>      and may > make unnecessary to place calls on VM in the first
>> place.
>>
>> think it can work.  Just it depends on many things.
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 2 Apr 2007 09:32:28 -0400

I don't think Henry was saying only there -- just that that might be
another deployment we haven't thought about. I am pretty sure he is
very much in favor of having them in wireless devices.

Personally, I think that putting P2PSIP peers in edge devices would be
a good place to do it for home wireline users -- as Henry points out,
it avoids the NAT issue, among other things. Of course I would also
want to see them in UAs, softphones, wireless devices, maybe even
consumer devices, etc. (and I am sure Henry wants to see P2PSIP peers
everywhere too!)

David

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "Eric Cooper" <[email-masked]>
Date: Mon, 2 Apr 2007 13:16:52 -0400

> it avoids the NAT issue, among other things. 

Until some ISP NATs their networks.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 2 Apr 2007 12:07:09 -0700

Jeroen,

These are valid points.
As David Bryan has mentioned, we would like to have P2P SIP in all endpoints and in all devices.

Mobile devices require however the client protocol and I hope we will soon have a write-up to explain this.

Naïve question: How do we distinguish here between deployment scenario and usage scenario, unless we limit the usage scenario to the GUI capability?

Thanks, Henry

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Sunday, April 01, 2007 1:47 PM
To: Henry Sinnreich; Paul Kyzivat; Eunsoo Shim
Cc: P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; [email-masked]; [email-masked]; zhuxian
Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario

Henry,

Regards,
Jeroen

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Apr 2007 19:11:28 -0400

> - SIP peer in the cable access device,

These seem quite reasonable, assuming that a device connected at this 
point is able to function properly as a peer. (I haven't been following 
what the assumptions are about required network capabilities of peers.)

> - SIP peer in enterprise network integrated access device (IAD).

I think this depends greatly on what expectations / contractual 
guarantees the enterprise has. Its unclear to me what guarantees can be 
made about a P2PSIP network will be able to make, and its unclear what 
kind of infrastructure would be installed by/for someone willing to make 
guarantees.

	Paul

---

From: "Michael Slavitch" <[email-masked]>
Date: Mon, 2 Apr 2007 21:13:18 -0400

Sorry for being late into this discussion, but client-server based VM isn't
truly client-server anymore in anything but the smallest or most monolithic
of enterprise networks, in fact the reality is that most if not all
enterprise networks contain just peers and superpeers with the difference
being partially a marketing decision by the vendors, as you can charge much
more for the servers, and a policy decision made either automatically by a
software deployment system or by IT staff which wants to place supernodes
with data sinks on appropriate equipment. In a highly distributed
environment there are potentially hundreds of possible data sinks for a
given application, with the sink based on subnet or geographic location or
balanced load, this can change rapidly over time and does.

In the case of the Microsoft environment such policy is administered and
published between supernodes, ie servers, by Active Directory.  It is
advertised to mere peers through DNS.  There was much discussion a while ago
about building service discovery environment using DNS instead of a P2P
DHT.  It can be argued that a case study of a P2P example done using DNS is
any large Windows Server 2003 based Microsoft network with many servers and
many more clients that also run applications themselves and are not just
dumb terminals. This is almost certainly always the case in all enterprises.
The big difference between C/S SIP and P2PSIP is automation. What is true is
that the square peg in round hole of overloading DNS makes deployments
clumsy and brittle within the enterprise domain and completely unmanageable
and unpublishable outside the firewall which is why the buck stops there in
current enterprise networking products.

The difference between C/S and P2P is largely policy and semantics with the
biggest difference being that the decisions and rules are highly
distributed.  Apart from that they are not just friends, they are fraternal
twins.

Regards

Michael Slavitch

<https://firewall.objectworld.com/exchweb/bin/redir.asp?URL=http://www.objectworld.com/>

308 Legget Dr.
Ottawa Ontario
K2K 1Y6 Canada

<https://firewall.objectworld.com/exchweb/bin/redir.asp?URL=http://maps.google.ca/maps?f=q%26hl=en%26q=308%2BLegget%2BDrive%2BOttawa%2BOntario%2BK2K%2B1Y6%26layer=%26sll=45.341061,-75.904541%26sspn=0.007119,0.023839%26ie=UTF8%26z=18%26ll=45.341061,-75.904541%26spn=0.00178,0.00596%26t=h%26om=1>

Michael Slavitch

Lead, Technology Initiatives

[email-masked]

PSTN:

+1.888.398.9698

x225

Fax:

+1.613.599.7457

Skype:

  Objectworld<https://firewall.objectworld.com/exchange/slavitch/Sent%20Items/Nortel,%20MSFT%20chase%20carriers%20with%20new%20hosted%20offering%20for%20SME%20and%20MME.EML/>

x225

<https://firewall.objectworld.com/exchange/slavitch/Sent%20Items/Nortel,%20MSFT%20chase%20carriers%20with%20new%20hosted%20offering%20for%20SME%20and%20MME.EML/>
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 2 Apr 2007 22:16:17 -0400

Actually, already being done... Good point. ;)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Apr 2007 08:57:28 -0400

Michael Slavitch wrote:
> Sorry for being late into this discussion, but client-server based VM 
> isn't truly client-server anymore in anything but the smallest or most 
> monolithic of enterprise networks, in fact the reality is that most if 
> not all enterprise networks contain just peers and superpeers with the 
> difference being partially a marketing decision by the vendors, as you 
> can charge much more for the servers, and a policy decision made either 
> automatically by a software deployment system or by IT staff which wants 
> to place supernodes with data sinks on appropriate equipment.

I'm sorry, but I don't understand the point you are trying to make 
above. You are trying to draw some sort of distinction, but I don't get 
it. Can you try again.

	Thanks,
	Paul

> In a 
> highly distributed environment there are potentially hundreds of 
> possible data sinks for a given application, with the sink based on 
> subnet or geographic location or balanced load, this can change rapidly 
> over time and does.
> 
> advertised to mere peers through DNS.  There was much discussion a while 
> ago about building service discovery environment using DNS instead of a 
> P2P DHT.  It can be argued that a case study of a P2P example done using 
> DNS is any large Windows Server 2003 based Microsoft network with many 
> servers and many more clients that also run applications themselves and 
> are not just dumb terminals. This is almost certainly always the case in 
> all enterprises. The big difference between C/S SIP and P2PSIP is 
> automation. What is true is that the square peg in round hole of 
> overloading DNS makes deployments clumsy and brittle within the 
> enterprise domain and completely unmanageable and unpublishable outside 
> the firewall which is why the buck stops there in current enterprise 
> networking products.
> 
> The difference between C/S and P2P is largely policy and semantics with 
> the biggest difference being that the decisions and rules are highly 
> distributed.  Apart from that they are not just friends, they are 
> fraternal twins.
> 
> Regards
> 
> Michael Slavitch
> 
>  
> 
> 
> corp_2colour 
> [email-masked] <mailto:[email-masked]>
> 
> 	
> 
> PSTN: 
> 
> 	
> 
> +1.888.398.9698
> 
> 	
> 
> x225
> 
> Fax:
> 
> 	
> 
> +1.613.599.7457
> 
> 	
> 
>  
> 
> Skype:      
> 
> 	
> 
>   Objectworld

---

From: "Michael Slavitch" <[email-masked]>
Date: Tue, 3 Apr 2007 10:48:05 -0400

The point I am making is  that in the enterprise the actual topological deployments of SIP clients and servers, when implemented as software on generic computing platforms, as well as the mechanisms that make that deployment happen, are already very different world than the canonical IMS/CSSIP one which  assumes SIP as core monolithic servers, fixed enterprise network integrated access devices (IAD),  B2BUA demarks, network elements, and dumb fixed endpoints.  Taking a network as a whole enterprise application software using C/S SIP proxies and UA’s already approximates something that is close to what is being called P2PSIP, only in a manner that is highly proprietary, closed, somewhat brittle and baroque, local, and ad-hoc, with gaping ugly holes.  P2P has the potential to transform that.

Some points I take from the previous discussion:

“that a P2P setup will be *free*”

-           A P2P network may not be free, but the setup (provisioning) will be free, and automatic.  This is a major benefit only partially achieved in enterprise networks,  a benefit of great value to enterprises that is underserved by vendors.  There is no benefit in requiring complex deployments where automation can take its place.  Deployment is almost always the biggest cost of enterprise systems dwarfing the cost of the systems themselves.

“I think this depends greatly on what expectations / contractual guarantees the enterprise has. It’s unclear to me what guarantees can be made about a P2PSIP network will be able to make, and its unclear what kind of infrastructure would be installed by/for someone willing to make guarantees.”

-          That is why ‘expectations/contractual guarantees’ need to be built into the automation that exists in the P2P overlay.  Self-calculation of such performance metrics is already there in all enterprise devices, the difference being that while WMI/SNMP data is merely collected a P2PSIP network can act automatically based on the metrics within their own nodes, there is a collective ‘aha’ that forces behavior change based on strict contracts, aka rules.  An SLA is easier to maintain if the objects can react accordingly, for example a node with degrading service can notify that it is on the decline forcing others to take over.  

There is an old traffic engineering axiom about service guarantees: it can be achieved through two ways: over engineering or  automation.  P2PSIP allows for automation.

 David Oran wrote:

“I'm not saying this can't be made to work, only that it isn't immediately obvious that it has advantages over a classic application/server approach.”

The immediately obvious advantage to me is standardized ruggedized automation that has economies of scale and operates over multiple domains, eliminating the need for over-engineering,  detailed fussy provisioning,  and an army of people doing basic monitoring and care-and-feeding.  Automation is the key, a dynamic statistical network vs. one that is fixed and assumed deterministic will always win out over time given a fractal operating environment.   This is being done in fits and starts in the enterprise data center.   P2PSIP makes it much more comprehensive.   People want the world to be predictable and deterministic,  and C/S based systems reflect that. That is the biggest problem P2P faces because it flies in the face of tradition.   

Regards

Michael Slavitch

 

  <http://www.objectworld.com/> 

308 Legget Dr. 
Ottawa Ontario 
K2K 1Y6 Canada

  <http://maps.google.ca/maps?f=q&hl=en&q=308+Legget+Drive+Ottawa+Ontario+K2K+1Y6&layer=&sll=45.341061,-75.904541&sspn=0.007119,0.023839&ie=UTF8&z=18&ll=45.341061,-75.904541&spn=0.00178,0.00596&t=h&om=1> 

Michael Slavitch              

[email-masked]

PSTN:  

+1.888.398.9698

x225

Fax:

+1.613.599.7457

Skype:       

 Objectworld   

x225

  <skype:Objectworld> 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 8:57 AM
To: Michael Slavitch
Cc: Henry Sinnreich; P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; [email-masked]; [email-masked]; zhuxian
Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario

it. Can you try again.

                Thanks,

                Paul

 

-- 

-----------------------------------------------

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. 

Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp. 
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 3 Apr 2007 13:06:38 -0400

I think most enterprise "PBX" vendors will tell you that the things you can
automate about provisioning have been automated, and you won't get much a
win there.  It's things like TN assignment, and dial plans, and gateway
routing, and emergency call provisioning, and permissions, and feature
enabling, etc, etc that dominate provisioning of enterprise telephony
systems.  P2P doesn't help any of that.

I worry, quite a bit, that perpetuating SIP UAs (the SIP client) will
perpetuate the dumb endpoint model, simply because the way they are made now
is that they are dumb endpoints.  They didn't have to be (SIP was originally
designed for smart endpoints).  If we make P2PSIP endpoints more closely fit
the smart endpoint model, then we make the peer that serves the UAs be the
smart box in the middle of the network.

Brian

  _____  

From: Michael Slavitch [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 10:48 AM
To: Paul Kyzivat
Cc: P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; Henry
Sinnreich; [email-masked]; [email-masked]
Subject: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

The point I am making is  that in the enterprise the actual topological
deployments of SIP clients and servers, when implemented as software on
generic computing platforms, as well as the mechanisms that make that
deployment happen, are already very different world than the canonical
IMS/CSSIP one which  assumes SIP as core monolithic servers, fixed
enterprise network integrated access devices (IAD),  B2BUA demarks, network
elements, and dumb fixed endpoints.  Taking a network as a whole enterprise
application software using C/S SIP proxies and UA's already approximates
something that is close to what is being called P2PSIP, only in a manner
that is highly proprietary, closed, somewhat brittle and baroque, local, and
ad-hoc, with gaping ugly holes.  P2P has the potential to transform that.

"that a P2P setup will be *free*"

-       A P2P network may not be free, but the setup (provisioning) will be
free, and automatic.  This is a major benefit only partially achieved in
enterprise networks,  a benefit of great value to enterprises that is
underserved by vendors.  There is no benefit in requiring complex
deployments where automation can take its place.  Deployment is almost
always the biggest cost of enterprise systems dwarfing the cost of the
systems themselves.

"I think this depends greatly on what expectations / contractual guarantees
the enterprise has. It's unclear to me what guarantees can be made about a
P2PSIP network will be able to make, and its unclear what kind of
infrastructure would be installed by/for someone willing to make
guarantees."

-      That is why 'expectations/contractual guarantees' need to be built
into the automation that exists in the P2P overlay.  Self-calculation of
such performance metrics is already there in all enterprise devices, the
difference being that while WMI/SNMP data is merely collected a P2PSIP
network can act automatically based on the metrics within their own nodes,
there is a collective 'aha' that forces behavior change based on strict
contracts, aka rules.  An SLA is easier to maintain if the objects can react
accordingly, for example a node with degrading service can notify that it is
on the decline forcing others to take over.  

There is an old traffic engineering axiom about service guarantees: it can
be achieved through two ways: over engineering or  automation.  P2PSIP
allows for automation.

 David Oran wrote:

"I'm not saying this can't be made to work, only that it isn't immediately
obvious that it has advantages over a classic application/server approach."

The immediately obvious advantage to me is standardized ruggedized
automation that has economies of scale and operates over multiple domains,
eliminating the need for over-engineering,  detailed fussy provisioning,
and an army of people doing basic monitoring and care-and-feeding.
Automation is the key, a dynamic statistical network vs. one that is fixed
and assumed deterministic will always win out over time given a fractal
operating environment.   This is being done in fits and starts in the
enterprise data center.   P2PSIP makes it much more comprehensive.   People
want the world to be predictable and deterministic,  and C/S based systems
reflect that. That is the biggest problem P2P faces because it flies in the
face of tradition.   

Regards

Michael Slavitch

 

 <http://www.objectworld.com/> corp_2colour

308 Legget Dr. 
Ottawa Ontario 
K2K 1Y6 Canada

<http://maps.google.ca/maps?f=q&hl=en&q=308+Legget+Drive+Ottawa+Ontario+K2K+
1Y6&layer=&sll=45.341061,-75.904541&sspn=0.007119,0.023839&ie=UTF8&z=18&ll=4
5.341061,-75.904541&spn=0.00178,0.00596&t=h&om=1> 

Michael Slavitch              

[email-masked]

PSTN:  

+1.888.398.9698

x225

Fax:

+1.613.599.7457

Skype:       

 Objectworld   

x225

 <skype:Objectworld> 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 8:57 AM
To: Michael Slavitch
Cc: Henry Sinnreich; P2PSIP Mailing List; Michael Hammer (mhammer); David R
Oran; [email-masked]; [email-masked]; zhuxian
Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario

it. Can you try again.

                Thanks,

                Paul

<https://firewall.objectworld.com/exchweb/bin/redir.asp?URL=http://www.objec
tworld.com/>

<https://firewall.objectworld.com/exchweb/bin/redir.asp?URL=http://maps.goog
le.ca/maps?f=q%26hl=en%26q=308%2BLegget%2BDrive%2BOttawa%2BOntario%2BK2K%2B1
Y6%26layer=%26sll=45.341061,-75.904541%26sspn=0.007119,0.023839%26ie=UTF8%26
z=18%26ll=45.341061,-75.904541%26spn=0.00178,0.00596%26t=h%26om=1>

<https://firewall.objectworld.com/exchange/slavitch/Sent%20Items/Nortel,%20M
SFT%20chase%20carriers%20with%20new%20hosted%20offering%20for%20SME%20and%20
MME.EML/>   

<https://firewall.objectworld.com/exchange/slavitch/Sent%20Items/Nortel,%20M
SFT%20chase%20carriers%20with%20new%20hosted%20offering%20for%20SME%20and%20
MME.EML/>

 

-- 

BEGIN-ANTISPAM-VOTING-LINKS

------------------------------------------------------

Teach CanIt if this mail (ID 657805) is spam:

Spam:
http://canitpro-int.objectworld.com/canit/b.php?i=657805&m=2eb1fdee55b7&c=s

Not spam:
http://canitpro-int.objectworld.com/canit/b.php?i=657805&m=2eb1fdee55b7&c=n

Forget vote:
http://canitpro-int.objectworld.com/canit/b.php?i=657805&m=2eb1fdee55b7&c=f

------------------------------------------------------

END-ANTISPAM-VOTING-LINKS

  _____  

This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.

Any views, opinions and content presented in this e-mail are solely those of
the author and may not represent those of Objectworld Communications Corp.

---

From: "Michael Slavitch" <[email-masked]>
Date: Tue, 3 Apr 2007 13:58:02 -0400

"vendors will tell you the things you can automate about provisioning
have been automated."

The vendors will tell you this because the things that they automate can
be summarized as:

1.       "not much".

2.       What we automate is our proprietary stuff, sod the rest.

t's things like TN assignment, and dial plans, and gateway routing, and
emergency call provisioning, and permissions, and feature enabling, etc,
etc that dominate provisioning of enterprise telephony systems.  P2P
doesn't help any of that.

I strongly disagree with that.   Look at the documentation for products
from many of the major vendors, there are stacks of complex details
regarding deployment,  not very automatic at all, with many of them
depending on crufty TFTP or FTP with fixed file locations for
provisioning of endpoints.  It's horrible.

Secondly, "it doesn't help with any of that" is only true in a static
fixed universe where you provision once and go away and limit
functionality to very basic tasks.   Even in that world the number of
user change requests on a 2000 user system is on the order of .5%-1% of
all endpoints per day on today's relatively static systems, 10 to 20 per
day, and that's just basic stuff, done at gunpoint.  Routers used to
have only static routes too, and web pages were once coded by hand.   

Regards

Michael

		 	 
Michael Slavitch              

[email-masked]

From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 1:07 PM
To: Michael Slavitch; 'Paul Kyzivat'
Cc: 'P2PSIP Mailing List'; 'Michael Hammer (mhammer)'; 'David R Oran';
'Henry Sinnreich'; [email-masked]; [email-masked]
Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage
scenario

I think most enterprise "PBX" vendors will tell you that the things you
can automate about provisioning have been automated, and you won't get
much a win there.  It's things like TN assignment, and dial plans, and
gateway routing, and emergency call provisioning, and permissions, and
feature enabling, etc, etc that dominate provisioning of enterprise
telephony systems.  P2P doesn't help any of that.

I worry, quite a bit, that perpetuating SIP UAs (the SIP client) will
perpetuate the dumb endpoint model, simply because the way they are made
now is that they are dumb endpoints.  They didn't have to be (SIP was
originally designed for smart endpoints).  If we make P2PSIP endpoints
more closely fit the smart endpoint model, then we make the peer that
serves the UAs be the smart box in the middle of the network.

Brian

________________________________

The point I am making is  that in the enterprise the actual topological
deployments of SIP clients and servers, when implemented as software on
generic computing platforms, as well as the mechanisms that make that
deployment happen, are already very different world than the canonical
IMS/CSSIP one which  assumes SIP as core monolithic servers, fixed
enterprise network integrated access devices (IAD),  B2BUA demarks,
network elements, and dumb fixed endpoints.  Taking a network as a whole
enterprise application software using C/S SIP proxies and UA's already
approximates something that is close to what is being called P2PSIP,
only in a manner that is highly proprietary, closed, somewhat brittle
and baroque, local, and ad-hoc, with gaping ugly holes.  P2P has the
potential to transform that.

-           A P2P network may not be free, but the setup (provisioning)
will be free, and automatic.  This is a major benefit only partially
achieved in enterprise networks,  a benefit of great value to
enterprises that is underserved by vendors.  There is no benefit in
requiring complex deployments where automation can take its place.
Deployment is almost always the biggest cost of enterprise systems
dwarfing the cost of the systems themselves.

"I think this depends greatly on what expectations / contractual
guarantees the enterprise has. It's unclear to me what guarantees can be
made about a P2PSIP network will be able to make, and its unclear what
kind of infrastructure would be installed by/for someone willing to make
guarantees."

-          That is why 'expectations/contractual guarantees' need to be
built into the automation that exists in the P2P overlay.
Self-calculation of such performance metrics is already there in all
enterprise devices, the difference being that while WMI/SNMP data is
merely collected a P2PSIP network can act automatically based on the
metrics within their own nodes, there is a collective 'aha' that forces
behavior change based on strict contracts, aka rules.  An SLA is easier
to maintain if the objects can react accordingly, for example a node
with degrading service can notify that it is on the decline forcing
others to take over.  

There is an old traffic engineering axiom about service guarantees: it
can be achieved through two ways: over engineering or  automation.
P2PSIP allows for automation.

 David Oran wrote:

"I'm not saying this can't be made to work, only that it isn't
immediately obvious that it has advantages over a classic
application/server approach."

The immediately obvious advantage to me is standardized ruggedized
automation that has economies of scale and operates over multiple
domains, eliminating the need for over-engineering,  detailed fussy
provisioning,  and an army of people doing basic monitoring and
care-and-feeding.  Automation is the key, a dynamic statistical network
vs. one that is fixed and assumed deterministic will always win out over
time given a fractal operating environment.   This is being done in fits
and starts in the enterprise data center.   P2PSIP makes it much more
comprehensive.   People want the world to be predictable and
deterministic,  and C/S based systems reflect that. That is the biggest
problem P2P faces because it flies in the face of tradition.   

Regards

Michael Slavitch

 

308 Legget Dr. 
Ottawa Ontario 
K2K 1Y6 Canada

<http://maps.google.ca/maps?f=q&hl=en&q=308+Legget+Drive+Ottawa+Ontario+
K2K+1Y6&layer=&sll=45.341061,-75.904541&sspn=0.007119,0.023839&ie=UTF8&z
=18&ll=45.341061,-75.904541&spn=0.00178,0.00596&t=h&om=1> 

Michael Slavitch              

[email-masked]

PSTN:  

+1.888.398.9698

x225

Fax:

+1.613.599.7457

Skype:       

 Objectworld   

x225

  <skype:Objectworld> 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 8:57 AM
To: Michael Slavitch
Cc: Henry Sinnreich; P2PSIP Mailing List; Michael Hammer (mhammer);
David R Oran; [email-masked]; [email-masked]; zhuxian
Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario

it. Can you try again.

                Thanks,

                Paul

<https://firewall.objectworld.com/exchweb/bin/redir.asp?URL=http://www.o
bjectworld.com/>

<https://firewall.objectworld.com/exchweb/bin/redir.asp?URL=http://maps.
google.ca/maps?f=q%26hl=en%26q=308%2BLegget%2BDrive%2BOttawa%2BOntario%2
BK2K%2B1Y6%26layer=%26sll=45.341061,-75.904541%26sspn=0.007119,0.023839%
26ie=UTF8%26z=18%26ll=45.341061,-75.904541%26spn=0.00178,0.00596%26t=h%2
6om=1>

<https://firewall.objectworld.com/exchange/slavitch/Sent%20Items/Nortel,
%20MSFT%20chase%20carriers%20with%20new%20hosted%20offering%20for%20SME%
20and%20MME.EML/>   

<https://firewall.objectworld.com/exchange/slavitch/Sent%20Items/Nortel,
%20MSFT%20chase%20carriers%20with%20new%20hosted%20offering%20for%20SME%
20and%20MME.EML/>

 

-- 

________________________________

This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.

Any views, opinions and content presented in this e-mail are solely
those of the author and may not represent those of Objectworld
Communications Corp.

________________________________

Spam
<http://canitpro-int.objectworld.com/canit/b.php?i=657949&m=5b6a6dc0fe34
&c=s> 
Not spam
<http://canitpro-int.objectworld.com/canit/b.php?i=657949&m=5b6a6dc0fe34
&c=n> 
Forget previous vote
<http://canitpro-int.objectworld.com/canit/b.php?i=657949&m=5b6a6dc0fe34
&c=f>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 3 Apr 2007 14:52:47 -0700

I agree with Michael here. The voice-only PBX is pathetic as an
enterprise communication and productivity platform (no presence, IM, no
integration with apps, etc.) is also exactly the opposite of what self
organizing systems provide. As for the usability of those tiny screens
and remembering the various commands...

Why not just use Skype PC clients or Skype phones instead? At least,
they are WiFi and no configuration is required that cannot be done by
the user. And they can be used on travel as well.

Just think what self organizing and usability means for the maintenance
headcount and budget. Not to mention the associated IT systems.

P2P SIP in the enterprise is not a PBX replacement any more that SIP is
a PSTN replacement, though many decisions makers have not given up :-)

Thanks, Henry

From: Michael Slavitch [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 12:58 PM
To: Brian Rosen; Paul Kyzivat
Cc: P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; Henry
Sinnreich; [email-masked]; [email-masked]
Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage
scenario

1.      "not much".

Regards

Michael

 

Michael Slavitch              

[email-masked]

 

Brian

-       A P2P network may not be free, but the setup (provisioning) will
be free, and automatic.  This is a major benefit only partially achieved
in enterprise networks,  a benefit of great value to enterprises that is
underserved by vendors.  There is no benefit in requiring complex
deployments where automation can take its place.  Deployment is almost
always the biggest cost of enterprise systems dwarfing the cost of the
systems themselves.

 David Oran wrote:

Regards

Michael Slavitch

 

308 Legget Dr. 
Ottawa Ontario 
K2K 1Y6 Canada

Michael Slavitch              

[email-masked]

PSTN:  

+1.888.398.9698

x225

Fax:

+1.613.599.7457

Skype:       

 Objectworld   

x225

  <skype:Objectworld> 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 8:57 AM
To: Michael Slavitch
Cc: Henry Sinnreich; P2PSIP Mailing List; Michael Hammer (mhammer);

it. Can you try again.

                Thanks,

                Paul

 

-- 

Spam:
http://canitpro-int.objectworld.com/canit/b.php?i=657805&m=2eb1fdee55b7&
c=s

Not spam:
http://canitpro-int.objectworld.com/canit/b.php?i=657805&m=2eb1fdee55b7&
c=n

Forget vote:
http://canitpro-int.objectworld.com/canit/b.php?i=657805&m=2eb1fdee55b7&
c=f

Spam

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 09:59:04 -0400

Have you actually ever built an enterprise telephony system?  Maybe
installed a recent one?

Look, every product can be improved, and I do agree with Henry that the
enterprise telephony folks haven't caught on (or haven't figured out how to
make money on) presence and IM integration.  I think there have been plenty
of attempts to allow other app integration that have failed pretty much
completely despite what we would have thought.

My take on this is that enterprise IT (which now owns phones), demands the
level of feature set the enterprise PBX guys give them, are pretty much
afraid of doing any serious app interaction except in call centers, and
would not see any inherent benefit in p2p.  "Self Organizing" is not what we
are talking about any more than current systems are self organizing.  In
current systems, except in the very largest systems, there is a server, you
configure it, and plug the phones in.  They self configure.  The
configuration on the server is complex, but it's not something that needs a
large staff; in most enterprises I know, there is usually one guy (or
sometimes one per site) who maintains the configuration part time.  How much
less do you think you could get, and what do you think you could simplify
with p2p?

Skype?  In an enterprise?  Try talking to YOUR staff about that idea and see
how far you get.   Skype does not provide the feature set enterprise wants.
You can claim the staff doesn't know its business I suppose.

Let's take one simple example: dial plans.  Every enterprise has one.  Does
Skype?  What would p2p do for dial plans that any current system can't do
right now?

What is the problem: dial plans are evil, we should get rid of them, or dial
plans are useful, and SOMEONE has to use some kind of tool to configure
them, and having done that, assign extension numbers within the dial plan?
What would p2p do for us?  D'you want users configuring their own
extensions?  

I see many benefits to p2p, but significantly simplifying enterprise
deployment isn't one of them.

Brian

  _____  

From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 5:53 PM
To: Michael Slavitch; Brian Rosen; Paul Kyzivat
Cc: P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran;
[email-masked]; [email-masked]
Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

I agree with Michael here. The voice-only PBX is pathetic as an enterprise
communication and productivity platform (no presence, IM, no integration
with apps, etc.) is also exactly the opposite of what self organizing
systems provide. As for the usability of those tiny screens and remembering
the various commands.

Why not just use Skype PC clients or Skype phones instead? At least, they
are WiFi and no configuration is required that cannot be done by the user.
And they can be used on travel as well.

P2P SIP in the enterprise is not a PBX replacement any more that SIP is a
PSTN replacement, though many decisions makers have not given up :-)

Thanks, Henry

  _____  

Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

"vendors will tell you the things you can automate about provisioning have
been automated."

The vendors will tell you this because the things that they automate can be
summarized as:

1.   "not much".

t's things like TN assignment, and dial plans, and gateway routing, and
emergency call provisioning, and permissions, and feature enabling, etc, etc
that dominate provisioning of enterprise telephony systems.  P2P doesn't
help any of that.

I strongly disagree with that.   Look at the documentation for products from
many of the major vendors, there are stacks of complex details regarding
deployment,  not very automatic at all, with many of them depending on
crufty TFTP or FTP with fixed file locations for provisioning of endpoints.
It's horrible.

Secondly, "it doesn't help with any of that" is only true in a static fixed
universe where you provision once and go away and limit functionality to
very basic tasks.   Even in that world the number of user change requests on
a 2000 user system is on the order of .5%-1% of all endpoints per day on
today's relatively static systems, 10 to 20 per day, and that's just basic
stuff, done at gunpoint.  Routers used to have only static routes too, and
web pages were once coded by hand.   

Regards

Michael

 

 

Michael Slavitch              

[email-masked]

 

Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

Brian

  _____  

-   That is why 'expectations/contractual guarantees' need to be built into
the automation that exists in the P2P overlay.  Self-calculation of such
performance metrics is already there in all enterprise devices, the
difference being that while WMI/SNMP data is merely collected a P2PSIP
network can act automatically based on the metrics within their own nodes,
there is a collective 'aha' that forces behavior change based on strict
contracts, aka rules.  An SLA is easier to maintain if the objects can react
accordingly, for example a node with degrading service can notify that it is
on the decline forcing others to take over.  

 David Oran wrote:

Regards

Michael Slavitch

 

308 Legget Dr. 
Ottawa Ontario 
K2K 1Y6 Canada

Michael Slavitch              

[email-masked]

PSTN:  

+1.888.398.9698

x225

Fax:

+1.613.599.7457

Skype:       

 Objectworld   

x225

 <skype:Objectworld> 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 8:57 AM
To: Michael Slavitch
Cc: Henry Sinnreich; P2PSIP Mailing List; Michael Hammer (mhammer); David R

it. Can you try again.

                Thanks,

                Paul

 

-- 

Spam:

Not spam:

Forget vote:

  _____  

  _____  

Spam
<http://canitpro-int.objectworld.com/canit/b.php?i=657949&m=5b6a6dc0fe34&c=s
Not
<http://canitpro-int.objectworld.com/canit/b.php?i=657949&m=5b6a6dc0fe34&c=n
>  spam
Forget
<http://canitpro-int.objectworld.com/canit/b.php?i=657949&m=5b6a6dc0fe34&c=f
>  previous vote

  _____

---

From: "Eric Cooper" <[email-masked]>
Date: Wed, 4 Apr 2007 10:20:21 -0400

> deployment isn't one of them.

I know of a couple of major enterprise PBX vendors who offer 1 and 2 week-long training courses so that their VARs can learn to install and configure the PBX.  Having had the training, it will generally take an hour or two of configuration before the PBX gets to the point where two extensions can call each other.

On the other hand, there are P2P PBX systems emerging that can be unboxed, plugged in and start making calls in under 2 minutes.  So I'd have to say that P2P does have a lot to offer in this area.

Best Regards,

Eric.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 10:37:34 -0400

> I know of a couple of major enterprise PBX vendors who offer 1 and 2 week-
> long training courses so that their VARs can learn to install and
> configure the PBX.  Having had the training, it will generally take an
> hour or two of configuration before the PBX gets to the point where two
> extensions can call each other.
> 
> On the other hand, there are P2P PBX systems emerging that can be unboxed,
> plugged in and start making calls in under 2 minutes.  So I'd have to say
> that P2P does have a lot to offer in this area.
With comparable feature sets?

I know of IP PBXs that can be unboxed, plugged in, and start making calls in
maybe 10 minutes.  I'm not sure the difference between 2 and 10 is that
significant.

What does p2p have, inherently, that makes it easier?  What makes the 2
minutes work that, say, Asterisk doesn't have?

I'll bet you its features.  If you have no features, everything is simple.
If you support any fraction of the feature set in an IP PBX, you're where
they are now.

I once made a small wager with someone that if IP PBX vendors offered
simpler systems at a lower price, they would make much more money: the idea
being that the complexity of the feature set had driven up the price of the
systems so far that buyers would trade simplicity for price.  I thought if
you gave them the "top 25" feature set, with roughly out-of-the-box
functionality, that nearly all enterprises would be satisfied.

He showed me a valid marketing study that showed, quite clearly, that I was
wrong.  Users DEMANDED the features.  They simply wouldn't purchase systems
that didn't have the features they wanted, and price wouldn't change their
mind (at least in the range of reasonable price differences).

Now, I'm not so sure if you asked the actual USERS of these systems if they
agreed.  But they don't make the purchase decisions.  The ones that do want
features.

The guys that run the big IP PBX businesses are not dumb.  They know their
customers.  If there was money to be made in 2 minute set up, they could
provide that right now (you can find some out there, do a web search).

But tell me anyways: what does p2p do that simplifies configuration for
enterprise?

Brian

---

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 4 Apr 2007 11:18:22 -0400

A  response to troll rant inline.  Only for the curious.  Apologies in
advance.

		 

Michael Slavitch              

[email-masked]

From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 9:59 AM
To: 'Henry Sinnreich'; Michael Slavitch; 'Paul Kyzivat'
Cc: 'P2PSIP Mailing List'; 'Michael Hammer (mhammer)'; 'David R Oran';
[email-masked]; [email-masked]
Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage
scenario

[MNS>  ]  Rather than being 'who do you think you are' condescending,
you might instead consider Google as your friend,  Brian.  Since you
asked, you might consider clicking on the logo in my signature.  Going
way back I built the IP stack on the Mitel SX-2000 in the late 1980's.
Back then it was considered novel to have provisioning over something
called 'telnet' . On the provisioning side things haven't progressed
much since then, but at least I got to prove my thesis advisor wrong as
indeed voice over packet won.  Apparently they are using the IP same
stack today, hopefully with all my bugs fixed. 

Look, every product can be improved, and I do agree with Henry that the
enterprise telephony folks haven't caught on (or haven't figured out how
to make money on) presence and IM integration.  I think there have been
plenty of attempts to allow other app integration that have failed
pretty much completely despite what we would have thought.

My take on this is that enterprise IT (which now owns phones), demands
the level of feature set the enterprise PBX guys give them, are pretty
much afraid of doing any serious app interaction except in call centers,
and would not see any inherent benefit in p2p.  "Self Organizing" is not
what we are talking about any more than current systems are self
organizing.

[MNS>  ] PBX vendors are afraid because it is too complicated and
applications are not in their DNA.  They push boxes. Applications are
fully in the DNA of others, however, especially enterprise IT
departments because applications are what they do.  Enterprise IT
departments are not afraid of building applications.  They are afraid of
touching brittle PBX systems with limited badly documented interfaces
from incompetent PBX vendors that want to charge a mint for basic CTI
that doesn't even work. Want a reference? I have several.  BTW: Have you
been reading the trade press lately?  For the record: My interest is not
in improving PBX products. My interest is eliminating them and replacing
them with software without forcing changes in end-user behavior.

In current systems, except in the very largest systems, there is a
server, you configure it, and plug the phones in.  They self configure.
The configuration on the server is complex, but it's not something that
needs a large staff; in most enterprises I know, there is usually one
guy (or sometimes one per site) who maintains the configuration part
time.  How much less do you think you could get, and what do you think
you could simplify with p2p?

[MNS>  ] Well, that's true, at least in the press releases.  Reality
does differ.  I actually have real numbers: A cost reduction of at least
90% when moving from traditional PBX to well-automated C/S SIP, which is
what my employer currently does, and a further cost reduction of 90%
between C/S SIP and P2P SIP.  In the incumbent PBX case the biggest cost
of a deployment is almost always configuration and installation and
on-going maintenance.  In the last case the biggest cost of deployment
Want a reference?

Skype?  In an enterprise?  Try talking to YOUR staff about that idea and
see how far you get.   Skype does not provide the feature set enterprise
wants.  You can claim the staff doesn't know its business I suppose.

[MNS>  ]  Oracle? Selling SIP servers? Try talking to IT staff  and see
how far you get.  Skype? Supporting one-click monetization and
settlement with millions of customers over voice and other media? Why
would a business want that
<http://www.e2exchange.com-a.googlepages.com/skype4e.pps> ? Why would
someone like me put a Skype address in his signature?

Let's take one simple example: dial plans.  Every enterprise has one.
Does Skype?  What would p2p do for dial plans that any current system
can't do right now?

[MNS>  ] I'd love to get into that but that would be under NDA and the
IETF has strict rules about disclosure, sorry.

What is the problem: dial plans are evil, we should get rid of them, or
dial plans are useful, and SOMEONE has to use some kind of tool to
configure them, and having done that, assign extension numbers within
the dial plan?  What would p2p do for us?  D'you want users configuring
their own extensions?  

[MNS>  ] NDA again and rules about disclosure. Sorry.   This is after
all a competitive industry.

[MNS>  ] Excellent!  You must understand that in my line of work this is
considered a very positive development and confirmation. Money in the
bank. Thanks.

---

From: "Eric Cooper" <[email-masked]>
Date: Wed, 4 Apr 2007 11:56:48 -0400

One small example:  P2P systems are fault-tolerant, so there's no need to configure the addresses of the 'fail-over' servers.

More to the general point, and this is just my opinion of course...I think centralized systems could approach the ease of configuration that is inherent in P2P systems, but in general they don't.  

Easy configuration is a 'nice-to-have' for centralized systems, but it's a necessity for P2P systems.

Best Regards,

Eric.

---

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 4 Apr 2007 12:33:02 -0400

Eric Cooper [email-masked] said something I consider rather
key.   My comments are inline.

"P2P systems are fault-tolerant, so there's no need to configure the
addresses of the 'fail-over' servers.

More to the general point, and this is just my opinion of course...I
think centralized systems could approach the ease of configuration that
is inherent in P2P systems, but in general they don't.

MNS> They can be (they better be, that's what I do for a living) but
doing so is much harder than people think especially with existing
multivendor product with multiple slightly different to be totally
incompatible flavours of largely the same thing.   Look at how hard it
is for Microsoft to automate plug-and-play components. 

 Given x units of work to produce a 'must have' feature that somebody
WILL buy and 10x units of work to produce ease of configuration that a
lot of people MAY buy guess which gets priority unless 'ease of use' is
a core value of the organization or it is forced down their throats by
customers.   I still know engineers who think the iPod is stupid because
it is too simple and doesn't have enough buttons or widgets.

Easy configuration is a 'nice-to-have' for centralized systems, but it's
a necessity for P2P systems."

All it takes is a good sales team to turn "nice to have" into "RFP
Mandatory", especially when the "nice to have" becomes "former OPEX
budget gets used for my other CAPEX/OPEX stuff".    Oracle's entire
sales strategy is to pay for increased Oracle CAPEX/OPEX out of reduced
telecom/noc CAPEX/OPEX.  The Oracle IT guys in a company hit the PBX
guys with an ugly club, take over their OPEX/CAPEX budget delivering the
same capabilities, and buy Oracle stuff with what's left, which is
exactly how Cisco has sold VOIP to the NOC for the past several years.
Both Oracle and Cisco salespeople are REALLY good at explaining how to
get away with budget murder, and until recently each company seemed
content at picking at the weaklings before turning on each other, as
they're both getting ready for a fight with Big Redmond Bill.   The same
battles apply even with little fish down to the SME, but as you go down
the food chain automation and ease of deployment become increasingly
important as you can't bury deployment costs in professional services.
When it comes down to it, the big battle isn't about technology but
budget.

If you want a very diplomatically worded description of OPEX Budget
Murder the above please see my employer's website for a customer case
study or send me an email and I'll give you a PDF copy.

Regards

Michael

Michael Slavitch              

[email-masked]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Michael Slavitch
Sent: Wednesday, April 04, 2007 12:05 PM
To: Michael Slavitch
Subject: Fwd: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage
scenario

---------- Forwarded message ----------

FromDate: Apr 4, 2007 11:56 AM

Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage
scenario

To: Brian Rosen <[email-masked]>, Henry Sinnreich

<[email-masked]>, Michael Slavitch <[email-masked]>,

Paul Kyzivat <[email-masked]>

Cc: David R Oran <[email-masked]>, P2PSIP Mailing List

<[email-masked]>, "Michael Hammer (mhammer)" <[email-masked]>

One small example:  P2P systems are fault-tolerant, so there's no need

to configure the addresses of the 'fail-over' servers.

More to the general point, and this is just my opinion of course...I

think centralized systems could approach the ease of configuration

that is inherent in P2P systems, but in general they don't.

Easy configuration is a 'nice-to-have' for centralized systems, but

it's a necessity for P2P systems.

Best Regards,

Eric.

----- Original Message -----

To: "'Eric Cooper'" <[email-masked]>; "'Henry Sinnreich'"

<[email-masked]>; "'Michael Slavitch'" <[email-masked]>;

"'Paul Kyzivat'" <[email-masked]>

Cc: "'David R Oran'" <[email-masked]>; "'P2PSIP Mailing List'"

<[email-masked]>; "'Michael Hammer (mhammer)'" <[email-masked]>

 

P2PSIP mailing list

[email-masked]

 

--

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 4 Apr 2007 10:19:32 -0700

Can we just replace the MUST have with MAY have?

Or just avoid the murders by skilled sales organizations "sales team to
turn "nice to have" into "RFP Mandatory"

And specify MUST NOT have PBX features?

I prefer the GPS on the Blackberry to any PBX features any time!

Thanks, Henry

From: Michael Slavitch [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 11:33 AM
To: [email-masked]; [email-masked]; Henry Sinnreich;
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage
scenario

Regards

Michael

Michael Slavitch              

[email-masked]

 

---------- Forwarded message ----------

 

Best Regards,

Eric.

----- Original Message -----

 

P2PSIP mailing list

[email-masked]

 

-- 

Teach CanIt if this mail (ID 658457) is spam:

Spam:
http://canitpro-int.objectworld.com/canit/b.php?i=658457&m=1cd3bc5403d2&
c=s

Not spam:
http://canitpro-int.objectworld.com/canit/b.php?i=658457&m=1cd3bc5403d2&
c=n

Forget vote:
http://canitpro-int.objectworld.com/canit/b.php?i=658457&m=1cd3bc5403d2&
c=f

---

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 4 Apr 2007 14:23:05 -0400

I believe that it should be as follows:

A P2PSIP nodye MAY have features.      //no need to get specific on what
features it MAY have.  Another word for feature is SERVICE.

A feature MUST BE  a logical representation of a repeatable
communications function that has a specified outcome or result. 

A feature MUST BE self-contained.

A feature MAY BE composed of other features.

Features are environment-specific - they are constrained or enabled by
context and must be described within that context. 

A feature MUST be a black box to users of the feature.

A feature MUST conform to strong governance regarding service
representation and implementation.

     ALL features MUST be FULLY ADVERTISED to P2P members that have
global credentials (ie,  I won't sign you if you have seekrit features).

    (ALL features MUST be signed* by P2P members that have appropriate
credentials)*  // Boss node knows all features and decides which get
used.

     ALL feature interfaces MUST be FULLY DESCRIBED with a machine
readable definition as per definition RFCXXXX (BNF/XML?).

     A feature must offer a "Litmus Test", which determines a service
guarantee as per RFCXXXX.  //takes care of service guarantees.

This looks a lot like the Open Group definition of SOA.   We will all
get much better paying jobs renaming P2PSIP as SOASIP.

Regards

M

 

		 	 
Michael Slavitch              

[email-masked]

From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 1:20 PM
To: Michael Slavitch; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage
scenario

Thanks, Henry

Regards

Michael

Michael Slavitch              

[email-masked]

 

---------- Forwarded message ----------

 

Best Regards,

Eric.

----- Original Message -----

 

P2PSIP mailing list

[email-masked]

 

--

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 16:27:25 -0400

That doesn't seem to get you a very big win.  Telling on server the hostname
of another for fault tolerant purposes is pretty simple.

Of course, we don't know how bootstrapping is going to work, but most
systems depend on configuring more than one bootstrap server address in
every peer.  Isn't that the same thing?

Of course, this also depends on your definition of "fault tolerant".

The one I am used to goes like this:

- Calls already up stay up and terminate normally

- Calls in the process of being set up may fail the set-up, but a retry must
work.  The user should not be aware the fault occurred.

- The next call placed after the failure occurs (and the fact of the failure
communicated) completes normally.  There can be no critical windows where
calls fail to complete.

Now, to be sure, in commercial systems, there is one more: call detail
records must always complete for every completed or attempted call.

Hopefully, what we design will do that.

This one puzzles me more than a little:
> More to the general point, and this is just my opinion of course...I think
> centralized systems could approach the ease of configuration that is
> inherent in P2P systems, but in general they don't.

Right, so you are agreeing with my basic premise.  There is nothing inherent
in p2p that makes configuration easier.  You are hopeful that we won't
repeat the mistakes we made in designing generic SIP based systems when we
had the TDM systems to see what they did wrong.  When we design p2psip
systems, we'll know better.  Yeah, right.

Actually, what we will have to work with is the really complex SIP
configuration framework.  We'll have a standardized way to do something that
really is inherently complex.  That will help some, but not a lot, because,
ah, configuration of telephony is inherently complex.  We know that, we just
would rather believe p2psip is the Great Simplifying Principle.

Brian

> From: Eric Cooper [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2007 11:57 AM
> To: Brian Rosen; 'Henry Sinnreich'; 'Michael Slavitch'; 'Paul Kyzivat'
> Cc: 'David R Oran'; 'P2PSIP Mailing List'; 'Michael Hammer (mhammer)'
> Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario
> 
> One small example:  P2P systems are fault-tolerant, so there's no need to
> configure the addresses of the 'fail-over' servers.
> 
> More to the general point, and this is just my opinion of course...I think
> centralized systems could approach the ease of configuration that is
> inherent in P2P systems, but in general they don't.
>

---

From: EdPimentl <[email-masked]>
Date: Wed, 4 Apr 2007 16:50:28 -0400

Though it is true that Telecom Service is complex... (We are no longer
tie to Tirks and WaffC)
It does not have to be.

Back in 1999 we fully automated OSS/BSS,  and fully automated
Pre-Ordering, Order Entry, Order Order Decomposioning, Order
Management, Order WorkFlow, Jeopardies, FCAPS, Network Provisioning,
Service Provisioning, Service Assurance, Billing and Customer Care.
Later, we were the first company that tie OSSj to a XML WebServices
SOA platform. using BPEL and ESB..

Much of what is being intimated here is part of OSS/BSS which can be
expose as Webservices API into a robust commercial P2P Overlay and
does not need to be built in into the Overlay.
I would be glad to socialized this outside of this mailing list and
then contribute the finding as a draft or a document for others to
comment.

Also there will be many cases where the above will be overkill and
will be like lighting a cigarette with a torch.

My .02 cents

-E

--
Thanks in advance and best regards,

Ed Pimentel
AgileCO
Founder

Mail:   edpimentl[at]gmail.com
sip:    sip:[email-masked]
IM:     edpimentl [AOL | Jabber | Yahoo | MSN ]
Voip:   edpimentl [SKype | GoogleTalk ]

Mobile Content Marketing/Management/Digital Delivery
http://mobilecentral.ws

Mobile ( Relevant, Ambient, Location ) based Social Network
http://TagR.mobi (Alpha)

Mobile Payment - P2P Payment
http://agilepay.ws

Sponsor of P2PSIP  open source [viasip_ng] project
Creating a standards base P2PSIP dSIP infrastructure
https://sourceforge.net/projects/viasip/
Mailing List [email-masked]

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 4 Apr 2007 14:11:11 -0700

> configuration framework.

The really complex SIP configuration framework we will _NOT work with_.
How much configuration is in a Skype UA or Skype phone?

1. Email address
2. Password
3. Inbound/Outbound phone number (optional) is selected from an
available pool and inserted in the download together with the crypto
keys.

Done!

Thanks, Henry

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 3:27 PM
To: 'Eric Cooper'; Henry Sinnreich; 'Michael Slavitch'; 'Paul Kyzivat'
Cc: 'David R Oran'; 'P2PSIP Mailing List'; 'Michael Hammer (mhammer)'
Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage
scenario

That doesn't seem to get you a very big win.  Telling on server the
hostname
of another for fault tolerant purposes is pretty simple.

- Calls in the process of being set up may fail the set-up, but a retry
must
work.  The user should not be aware the fault occurred.

- The next call placed after the failure occurs (and the fact of the
failure
communicated) completes normally.  There can be no critical windows
where
calls fail to complete.

think
> inherent in P2P systems, but in general they don't.

Right, so you are agreeing with my basic premise.  There is nothing
inherent
in p2p that makes configuration easier.  You are hopeful that we won't
repeat the mistakes we made in designing generic SIP based systems when
we
had the TDM systems to see what they did wrong.  When we design p2psip
systems, we'll know better.  Yeah, right.

Actually, what we will have to work with is the really complex SIP
configuration framework.  We'll have a standardized way to do something
that
really is inherently complex.  That will help some, but not a lot,
because,
ah, configuration of telephony is inherently complex.  We know that, we
just
would rather believe p2psip is the Great Simplifying Principle.

Brian

---

From: Dean Willis <[email-masked]>
Date: Wed, 4 Apr 2007 16:16:02 -0500

trimming the overextended cc list  . . .

On Apr 4, 2007, at 8:59 AM, Brian Rosen wrote:

>
> I see many benefits to p2p, but significantly simplifying  
> enterprise deployment isn’t one of them.
>
>
Hah. You may not have had the experience of trying to get multiple  
enterprise PBXes talking to each other.

Most enterprises can barely keep DNS working, and when you have a  
couple of thousand PBXes that have to be able to route calls between  
each other, the configuration gets ugly. We really DO need "self  
organizing".

Now factor in business-to-business and business-to-consumer calling  
without TDM trunks.

And oh yeah, firewall traversal.

Now, lets morph this into an even more fluid environment -- emergency  
responders or the like working in an ad-hoc (aka MANET, AODV) network  
with mixed 802.11 and 802.16 components.

There are dramatic potentials for P2P to help on all these fronts.

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 4 Apr 2007 17:25:56 -0400

SIP itself isn't complex to configure so that it works (you should  
only need a user name and Digest password, and possibly an outbound  
proxy, but we have a discovery mechanism for that). Unfortunately,  
people want to configure other stuff, mostly "policy" ("no, you can't  
use G.722"), dial plans, special servers, UI parameters (ring tones,  
etc.), non-default SIP timers, transport preferences, etc. None of  
these depend on P2P or disappear when using P2P, unless you just  
don't give users those choices. Skype and other consumer products are  
simpler to set up because they don't let the user configure T1, not  
because they discovered some P2P configuration magic. (Now, P2P  
systems may well use the P2P infrastructure to retrieve  
configuration, but that's not fundamentally different from  
downloading an XML file via HTTP.)

Henning

---

From: "Eric Cooper" <[email-masked]>
Date: Wed, 4 Apr 2007 17:43:15 -0400

Well perhaps I am just hopeful, but there is a difference between centralized server configuration and P2P configuration:  The server config is performed once, by a knowledgeable professional, whereas the P2P config will need to be performed millions of times by millions of end-users.

Is in an inherent principle of P2P that it is easier to configure than a centralized system.  No.  I'm sure we could concoct a system that requires a two-week training course and several hours of effort to get up and running.  Of course, no one would ever use it.

That should be a strong incentive to eliminate the configuration whenever possible (i.e. try to bootstrap via multicast or a cached list of bootstrap peers before resorting to configured addresses).

My guess is that our effort will probably fail if we don't manage to keep the configuration down to a very few items that the average end-user can understand.

I don't believe that P2P is the great simplifying principle.  I actually think that making things easy is quite hard, but a P2P system doesn't have the crutch of a 'system administrator' that we can force into doing all that complex configuration.  So we're going to have to eliminate as much configuration as we can and make the rest so easy that millions of grandmothers can do it.

Best Regards,

Eric.

---

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 4 Apr 2007 17:48:48 -0400

Inline:

Michael Slavitch              

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Wednesday, April 04, 2007 5:16 PM
To: Brian Rosen
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

On Apr 4, 2007, at 8:59 AM, Brian Rosen wrote:

> enterprise deployment isn't one of them.
>
>

[MNS>  ]  All the above? That's what I do.  It's hard, and the above scratches the surface.  You really don't want to know and if you want details buy lots of drinks. That's why I'm here salivating at the prospect of things being easier, and if not easier, and at this stage 'not horrible' will do just fine. Thanks.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 18:06:59 -0400

Inline

> Sent: Wednesday, April 04, 2007 5:49 PM
> To: Dean Willis; Brian Rosen
> Cc: P2PSIP Mailing List
Oh, I have, I have.

> each other, the configuration gets ugly. We really DO need "self
While I'd love to believe that it's possible to do this, I don't really
think it is.

I think we have to do things that are akin to maintain mail servers, at the
least, to make this work on top of the DNS.  If you expect it to work with
telephone numbers, we get even more fun.

Mostly, I don't see how p2p is the magic sauce that makes this possible.  I
also don't believe in "oh, but we HAVE to do it, it's a requirement",
without a hint as to how.

> Now factor in business-to-business and business-to-consumer calling
Ah, well, with a service provider or without?  If the latter, easy for the
enterprise.  If the former, pretty near impossible today for business to
consumer, getting more possible with business to business, but not yet any
enterprise purchasing push.

> And oh yeah, firewall traversal.
Yep, have to bite this bullet, but again p2p doesn't help.  At least we
understand how to do it (and it's complicated).   We can require that
everyone do it from day one.  Again, no protocol police.
> with mixed 802.11 and 802.16 components.
One of my favorite subjects.  Very interesting use case.  I think I
understand how we do this one, but it's possible only because they have
existing structures that we can build trust relationships off of.

> There are dramatic potentials for P2P to help on all these fronts.
On the ad-hoc front, I more or less understand.

I see lots of benefits to p2p for more conventional consumer/enterprise
calling, but see no proposed mechanism to solve hard configuration problems
in a better way then we have now for vanilla SIP.

> 
> 
> [MNS>  ]  All the above? That's what I do.  It's hard, and the above
> scratches the surface.  You really don't want to know and if you want
> details buy lots of drinks. That's why I'm here salivating at the prospect
> of things being easier, and if not easier, and at this stage 'not
> horrible' will do just fine. Thanks.
Very nice, and yes we want details.  Write an I-D and propose some please.
I'll buy all the 35 crown Pilsner Urquell you want the next time the IETF
meets in Prague.

Brian

---

From: Dean Willis <[email-masked]>
Date: Wed, 4 Apr 2007 18:13:57 -0500

> While I'd love to believe that it's possible to do this, I don't  

Then get the heck out of the way while we work on solving the problem!

> enterprise purchasing push.

Without, of course.

> everyone do it from day one.  Again, no protocol police.

We don't have any other  reasonable way to find STUN/TURN servers, so  
yeah, p2p helps.

> existing structures that we can build trust relationships off of.

Yep. I think this is one of the more doable things.

> in a better way then we have now for vanilla SIP.

The main things that gets easier to provision is internode routing.

Let's say I'm aware of an implementation of "conventional" SIP that  
requires root-level manual configuration of "SIP trunks" to get two  
PBXes from the same vendor to talk to each other.

The "conventional" counter-solution is to use DNS entries. Doesn't  
quite work, since we're in the same user namespace, and the user  
namespace is really distributed over the set of PBX nodes.

TRIP provides possibly another solution, but only for phone numbers.

Replace all this cruft with dynamic registration into a distributed  
database, and It Just Works.

Here's another scenario where the dynamic routing of P2P makes sense.

Assume a conventional IMS with 5 million uses and 50 S-CSCF nodes.  
Each user is dynamically assigned to an S-CSCF at registration time.  
A user binding is then placed into the HSS to map from user to S- 
CSCF. The HSS is hard to manage, scale, replicate, etc. Every phone  
call requires a couple of dips into the HSS to figure out the routing.

Replace HSS with P2PSIP. The originating side S-CSCF/peer transforms  
the R-URI into a resource ID. One DHT hash later, we have the peer ID  
of the terminating S-CSCF. Routing follows.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Apr 2007 08:47:53 -0400

Some interesting points Dean. These are starting to help.
Note that I am not "against" p2psip - I am still just a skeptic waiting 
to be convinced that this is not just the latest silver bullet.

Some comments inline.

	Paul

>> enterprise purchasing push.

Is it really possible to eliminate SPs (loosely defined) from this market?

Almost every customer will want to make calls to/from the PSTN. Either 
each customer has their own TDM interconnect or else they become the 
customer of somebody. Since TDM calls and phone numbers cost something I 
doubt this can be something that will be provided for free, so somebody 
ends up being a service provider. (I.e. Skype is a SP for TDM interconnect.)

Direct business-to-business and business-to-consumer calling without TDM 
doesn't necessarily require TDM trunks. But unless everybody is on the 
same p2p network it will require *something*. If addressing is via sip 
URIs then all it really requires is DNS and IP connectivity, which is 
perhaps what you mean. If the goal is connectivity via phone number 
addressing then it will still require ENUM.

> Assume a conventional IMS with 5 million uses and 50 S-CSCF nodes. Each 
> user is dynamically assigned to an S-CSCF at registration time. A user 
> binding is then placed into the HSS to map from user to S-CSCF. The HSS 
> is hard to manage, scale, replicate, etc. Every phone call requires a 
> couple of dips into the HSS to figure out the routing.
> 
> Replace HSS with P2PSIP. The originating side S-CSCF/peer transforms the 
> R-URI into a resource ID. One DHT hash later, we have the peer ID of the 
> terminating S-CSCF. Routing follows.

I think you just mixed up the domain of the caller with the domain of 
the callee. Fine if they are the same. Not fine if they are different.

I think we can safely assume that even if p2p is embraced for IMS, it 
won't mean that all IMS providers share a single DHT.

So it is just like the business-to-business discussion above.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Thu, 5 Apr 2007 11:46:23 -0500

> Is it really possible to eliminate SPs (loosely defined) from this  

Of course not. But their role will differ somewhat, and we can expect  
that they will not be required for all enterprise to enterprise  
communications. B2B does not require mediators, although it allows  
them. I predict SPs will split into two classes -- overlay  
maintainers, and gateway providers. Skype, of course, does both.

Consider what happened with enterprise email systems (I'll skip the  
UUCP story, as although influential, it's a different story).

In the beginning, it was a pure service provider play. My buddies at  
MCI got $2 per page of email sent through MCIMail. Everybody's  
address was in the MCIMail namespace, and it didn't talk to any other  
namespaces. If you wanted to email somebody on The Well, you had to  
dial in there instead. Same for CompuServ.

Then the email services began interconnecting using SMTP, and people  
started recognizing "@" style addressing for name spaces.

Some enterprises figured out that they could run their own email  
services, just like universities and national labs did, using the  
same software and protocols. At first the big email services refused  
to talk to them, and then it became commonplace.

Eventually a three-tier system emerged for enterprises. Big or  
technically astute enterprises ran their own email services. Mid- 
sized or very name conscious ones contracted with a service provider  
to represent them in the DNS namespace and host an appropriate email  
server. And little companies continued to use "service provider"  
hosting and namespace, like "business class" AOL.

Now, how does this apply to P2PSIP?

1) If the service-provider interface is CSSIP, the service provider  
has to find the other service providers to talk to. This is likely to  
be resolved by RFC 3263 procedures, but could also be resolved using  
P2PSIP between the service providers.

2) The relationship between end users (such as enterprises) and their  
gateway service providers could occur inside a P2PSIP model. Perhaps  
the enterprise and the gateway provider are members of the same overlay.

3) Enterprises that participate in the same overlay as each other can  
just use P2PSIP procedures between each other. This is especially  
useful for the small-to-medium business that can't figure out how (or  
don't want to pay to) to manage their own DNS entries and SIP  
gateways and things. Just sign up with an overlay, plug in an ICE- 
friendly router and some P2PSIP phones, and start talking. The  
overlay gets you to other enterprises in the overlay, gets you to a  
SIP gateway for destinations not on the overlay, and gets you to TDM  
gateway providers for users that have to be reached via TDM (although  
you might contract seperately for these gateway services).

> Almost every customer will want to make calls to/from the PSTN.  
> Either each customer has their own TDM interconnect or else they  
> become the customer of somebody. Since TDM calls and phone numbers  
> cost something I doubt this can be something that will be provided  
> for free, so somebody ends up being a service provider. (I.e. Skype  
> is a SP for TDM interconnect.)

Right. But in today's market, the service providers also require that  
they are the provider of IP interconnect. That won't hold up. It's  
entirely reasonable to provide your own IP interconnect, and use a  
service provider for TDM. Or use two entirely different service  
providers. Or maybe three -- one for overlay, one for TDM, and one  
for CSSIP.

>
> Direct business-to-business and business-to-consumer calling  
> without TDM doesn't necessarily require TDM trunks. But unless  
> everybody is on the same p2p network it will require *something*.  
> If addressing is via sip URIs then all it really requires is DNS  
> and IP connectivity, which is perhaps what you mean. If the goal is  
> connectivity via phone number addressing then it will still require  
> ENUM.

Within an overlay, no ENUM needed. ENUM is useful between overlays  
(at CSSIP gateways), which includes selecting a TDM gateway that is  
outside one's overlay.

>> Each user is dynamically assigned to an S-CSCF at registration  
>> time. A user binding is then placed into the HSS to map from user  
>> to S-CSCF. The HSS is hard to manage, scale, replicate, etc. Every  
>> phone call requires a couple of dips into the HSS to figure out  
>> the routing.
>> Replace HSS with P2PSIP. The originating side S-CSCF/peer  
>> transforms the R-URI into a resource ID. One DHT hash later, we  
>> have the peer ID of the terminating S-CSCF. Routing follows.
>
> I think you just mixed up the domain of the caller with the domain  
> of the callee. Fine if they are the same. Not fine if they are  
> different.

I tried to keep my example within a single IMS domain, which is  
roughly equivalent to keeping it within an overlay. If one is  
crossing between IMSes, this might well be equivalent to crossing  
between overlays, which we assume requries either 3262 procedures or  
fixed "trunk"style routing.

>
> I think we can safely assume that even if p2p is embraced for IMS,  
> it won't mean that all IMS providers share a single DHT.
>

Correct. They're more likely to use fixed inter-IMS trunking for the  
forseeable future.

> So it is just like the business-to-business discussion above.

yep.

--
Dean

---

From: "Michael Slavitch" <[email-masked]>
Date: Thu, 5 Apr 2007 14:20:49 -0400

I concur so much with Dean's description I may have to consider him a competitor. ;)

Michael Slavitch              

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Thursday, April 05, 2007 12:46 PM
To: Paul Kyzivat
Cc: 'P2PSIP Mailing List'
Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

yep.

--
Dean

--

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 5 Apr 2007 19:07:52 -0700

Michael,

I agree with what you say but just cannot understand why you assume IMS will matter for the Internet (it is supposed to be the last stand against the Internet) and even if so, on what basis do you assume IMS will ever change direction 180 degrees and adopt P2P? 

Isn't IMS all about everything in the network and the endpoints are under total control?

Mobile operators may see the light and adopt P2P, but would it be IMS as it is defined today?

Can you help and explain?

Thanks, Henry

-----Original Message-----
From: Michael Slavitch [mailto:[email-masked]] 
Sent: Thursday, April 05, 2007 1:21 PM
To: Dean Willis; Paul Kyzivat
Cc: P2PSIP Mailing List
Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

Michael Slavitch

---

From: <[email-masked]>
Date: Fri, 6 Apr 2007 16:42:13 +0200

Henry,

My 2-cents worth

IMS is often viewed, pushed or what ever you want as a defence against 'the Internet Model'. Orignially, it was position to provide Internet style services, buit remaining some control in the network.

There are some benefits for telco's in using IMS even if not used as a "last stand against The Internet". In that it provides some interfaces for billing, OSS/BSS en SIM authentication amongst others. 

Now I am a firm believer of open networks and deploying Application in end-to-end fashion. Although this is not always quite possible, eg when using SIP for PSTN Simulation services. I know it goes against many of your believes, but replacing TDM network technology with IP/ethernet networks and the demand from marketers to do this unintrusive for our customers, does not leave us with much choose. But, we are not trying to replace every feature (e.g. we abandon Call Completion services). I share your worry that too much focus is on standardization efforts to replicate the PSTN using SIP.
We would like to use IMS for more than PSTN, so we deploy it as open as possible and challenge our IMS vendor to implement basically a SIP Proxy. But not everyone shares this view, I admit.

Now, I do not see how P2P would be incorporated into IMS. It would render the HSS obsolete and hence IMS would loose much of it's value. I would say Dean's decription sounds like an interesting path for migrating IMS to P2P but not as a long term co-existence.

Colin Pons

-----Oorspronkelijk bericht-----
Van: Henry Sinnreich [mailto:[email-masked]] 
Verzonden: vrijdag 6 april 2007 4:08
Aan: Michael Slavitch; Dean Willis; Paul Kyzivat
CC: P2PSIP Mailing List
Onderwerp: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

Michael,

Thanks, Henry

-----Original Message-----
From: Michael Slavitch [mailto:[email-masked]] 
Sent: Thursday, April 05, 2007 1:21 PM
To: Dean Willis; Paul Kyzivat
Cc: P2PSIP Mailing List
Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

Michael Slavitch

---

From: Dean Willis <[email-masked]>
Date: Sat, 07 Apr 2007 01:10:49 -0500

[email-masked] wrote:
> 
> Now, I do not see how P2P would be incorporated into IMS. It would
> render the HSS obsolete and hence IMS would loose much of it's value.
> I would say Dean's decription sounds like an interesting path for
> migrating IMS to P2P but not as a long term co-existence.
> 

I would say, rather, that it transforms a complex and hard to maintain 
centralized HSS (or hierarchy of centralized HSS organized by a seperate 
but still centralized locator function) into an easier-to maintain and 
somewhat more robust distributed HSS with a fully-distributed and very 
fault-tolerant locator function.

I suppose one could even implement the PEER protocol "GET" and "PUT" 
functions using DIAMETER so that legacy systems couldn't really tell the 
difference ;-).

--
Dean

---

From: "Wei Gengyu" <[email-masked]>
Date: Sat, 7 Apr 2007 17:17:59 +0800

Something here at least.

The deployed HLR in a province here is centralized, and HLRs between provinces are peers.
The configuration of SCPs in IN are the same. 

The HSS should be centralized, but it is not to know how HSS will be organized.

So the peer-to-peere protocol may be used between the HLR or HSS of each province 
while the protocol in use is CAMEL, or the like.

Gengyu

---

From: "Michael Slavitch" <[email-masked]>
Date: Sun, 8 Apr 2007 14:46:28 -0400

Yes,  however the approach you describe is only possible in peer
protocols that support implicit structure and heirarchy otherwise
decisions regarding which node is authoritative will require a 3rd
party system,  which begins to defeat the purpose of the whole
enterprise.

---

From: "Michael Slavitch" <[email-masked]>
Date: Sun, 8 Apr 2007 15:08:53 -0400

Henry wrote:

"Isn't IMS all about everything in the network and the endpoints are
under total control?"

Yes.  However I fear that the flipside is no better, a pure-peer
environment without any control may create a tragedy of the Internet
commons, one that expects something for nothing without boundries or
checks and balances. There is a vast gulf between greedy Stalinist
totalitarianism and doctrinaire anarchy.

"Mobile operators may see the light and adopt P2P, but would it be IMS
as it is defined today?"

Certainly not.  IMS as it stands today will go the way of FDDI and ATM et al.

What a P2P successor will be called depends on who is doing the
marketing.  Gigabit Ethernet isn't coax CDMA either.  Just try buying
a token-ring or FDDI card.   If I had the answers to these questions
they'd be in a set of power-point slides doing the VC samba on Sand
Hill Road.

The mobiles will adopt it under the following circumstances:

1. It puts the issue of recurring revenues to bed long enough for a bond issue.
2. It permits a level of certainty regarding customer retention.
3. It allows them to offer different services at different prices to
different people.
4. It allows them to shrink their OPEX enough to make more and charge less.
5. It keeps E911/DHS/FBI/NSA happy enough.
6. It allows them to do what they do best, bury costs in ongoing
charges and fees.