Subject: 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

_______________________________________________
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: "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.

---

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

> 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. 

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/>

---

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.

---

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

________________________________

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

 

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: "Michael Slavitch" <[email-masked]>
Date: Tue, 3 Apr 2007 13:58:02 -0400

1.       "not much".

Regards

Michael

		 	 
Michael Slavitch              

[email-masked]

Brian

 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

---

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

 

-- 

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

Spam

---

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

On 4/1/07, Jeroen van Bemmel <[email-masked]> wrote:
> P2PSIP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/p2psip
>

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

---

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

Thanks, Henry

1.      "not much".

Regards

Michael

 

Michael Slavitch              

[email-masked]

 

Brian

 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:

Not spam:

Forget vote:

Spam

---

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

David

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

---

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

  _____  

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

 

 <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/>

 

-- 

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

  _____  

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: 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

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

[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.

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

[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: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 09:59:04 -0400

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 sFrom [email-masked] Thu Apr 05 08:05:22 2007
From: "Brian Rosen" <[email-masked]>
To: "'Henry Sinnreich'" <[email-masked]>,
	"'Michael Slavitch'" <[email-masked]>,
	"'Paul Kyzivat'" <[email-masked]>
Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario
Date: Wed, 4 Apr 2007 09:59:04 -0400
Cc: [email-masked], [email-masked], 'David R Oran' <[email-masked]>,
	'P2PSIP Mailing List' <[email-masked]>,
	"'Michael Hammer \(mhammer\)'" <[email-masked]>

This is a multi-part message in MIME format.
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 sFrom [email-masked] Thu Apr 05 08:05:22 2007
From: "Brian Rosen" <[email-masked]>
To: "'Henry Sinnreich'" <[email-masked]>,
	"'Michael Slavitch'" <[email-masked]>,
	"'Paul Kyzivat'" <[email-masked]>
Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario
Date: Wed, 4 Apr 2007 09:59:04 -0400
Cc: [email-masked], [email-masked], 'David R Oran' <[email-masked]>,
	'P2PSIP Mailing List' <[email-masked]>,
	"'Michael Hammer \(mhammer\)'" <[email-masked]>

This is a multi-part message in MIME format.
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?  

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]

 

From: Brian Rosen [mailto:[email-masked]] 
omething 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?  

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]

 

From: Brian Rosen [mailto:[email-masked]] 
omething 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?  

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:

The immediately obvious advantage to meSent: 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

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:

The immediately obvious advantage to meSent: 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

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

 is standardized ruggedized

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

 is standardized ruggedized

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

  _____