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

From: <[email-masked]>
Date: Wed, 4 Apr 2007 07:37:57 +0200

Henry,

I like your idea of deploying sip peers in edge devices. However, as an employee of a carrier I would like to see how a carrier is able to provide service asurance to be able to provide compliant handling. Many of our customers do not understand how to install these gateways themselves, let alone how to troubleshoot.

This is even more important for enterprises, which often  insist on SLAs which include troubleshoot resolution limits.

-----Original Message-----
From: "Paul Kyzivat" <[email-masked]>
To: "Henry Sinnreich" <[email-masked]>
Cc: "P2PSIP Mailing List" <[email-masked]>; "Michael Hammer (mhammer)" <[email-masked]>; "David R Oran" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: 3-4-07 01:11
Subject: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario

Henry Sinnreich wrote:
> 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,

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

> 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
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 4 Apr 2007 09:32:13 +0200

Colin,

With the right P2P software, the devices need no configuration at  
all, the configuration data can be derived from the "hardware id" and  
a preloaded X509 certificate while the mapping between services and  
the hardware can be done centralized and allow the business model the  
operator wishes with minimal opex.

Adrian

On Apr 4, 2007, at 7:37 AM, <[email-masked]> <[email-masked]>  
wrote:

> Henry,
>
> I like your idea of deploying sip peers in edge devices. However,  
> as an employee of a carrier I would like to see how a carrier is  
> able to provide service asurance to be able to provide compliant  
> handling. Many of our customers do not understand how to install  
> these gateways themselves, let alone how to troubleshoot.
>
> This is even more important for enterprises, which often  insist on  
> SLAs which include troubleshoot resolution limits.
>
> Cc: "P2PSIP Mailing List" <[email-masked]>; "Michael Hammer  
> (mhammer)" <[email-masked]>; "David R Oran" <[email-masked]>;  
> "[email-masked]" <[email-masked]>; "[email-masked]"  
> <[email-masked]>
> Sent: 3-4-07 01:11

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 4 Apr 2007 07:44:08 -0700

Colin, Paul,

Thanks for raising the valid issue about service assurance. 

As engineers, we know the service assurance is more than a piece of
legal paper and must be based on the following:

-          Adequate bandwidth,

-          Geographic diversity,

-          Simplicity; so things can be managed,

-          Security that can be audited,

-          Safe data retention: Replication and the geographic diversity
of peer nodes of the overlay,

-          Economy of scale: All peers have software with identical
behavior,

-          No configuration is required or possible. The customer just
plugs in the gateway box. This is real service automation.

-          Cost containment: P2P self configuration is unbeatable. Count
all the savings in CAPEX and OPEX by not having any network based VoIP
infrastructure. Save all that electricity and real estate in the data
centers.

-          Flexibility for new applications: The API between SIP and the
DHT overlay,

-          No lock-in from single source: The applications are in the
endpoints. Buy them from anywhere.

-          Automatic updates from the application provider: This is
current PC SW state of the art and works for both the (1) P2P software
in the access device and (2) for the application software, such as
presence, IM, voice, multimedia, etc. No or minimal is staff required.

-          Last but not least, besides SIP enabled communications, the
overlay can also serve for many other applications for your users:
Content distribution, application layer multicast for conferences,
directory search, IM+A/V chat rooms, name services, etc.

All of the above can be easily implemented by porting well documented
open source software into the residential access box or in the
integrated access device (IAD) for enterprises. Just check out
http://opendht.org/ and other similar sites.

Please don't take my word for it, just make for yourself a comparison
table for your network. If you can't share the comparison with the list,
can you share it with me in private? :-)

*       as an employee of a carrier

I worked most of my career for carriers, so that's what prompted the
above considerations.

Thanks, Henry

________________________________

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

Henry,

I like your idea of deploying sip peers in edge devices. However, as an
employee of a carrier I would like to see how a carrier is able to
provide service asurance to be able to provide compliant handling. Many
of our customers do not understand how to install these gateways
themselves, let alone how to troubleshoot.

This is even more important for enterprises, which often  insist on SLAs
which include troubleshoot resolution limits.

-----Original Message-----
From: "Paul Kyzivat" <[email-masked]>
To: "Henry Sinnreich" <[email-masked]>
Cc: "P2PSIP Mailing List" <[email-masked]>; "Michael Hammer (mhammer)"
<[email-masked]>; "David R Oran" <[email-masked]>; "[email-masked]"
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: 3-4-07 01:11
Subject: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario

        Paul

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 4 Apr 2007 09:24:35 -0700

Colin, Paul,

-          Adequate bandwidth,

-          Geographic diversity,

Thanks, Henry

Henry,

-----Original Message-----
From: "Paul Kyzivat" <[email-masked]>
To: "Henry Sinnreich" <[email-masked]>
Cc: "P2PSIP Mailing List" <[email-masked]>; "Michael Hammer (mhammer)"

        Paul