Subject: [p2p-sip] Requirements Explosion

From: drage at lucent.com (Drage, Keith (Keith))
Date: Wed, 11 Jan 2006 19:02:19 -0000

I'm afraid I have totally lost the purpose of this point-to-point SIP stuff - or rather I think some of the other members of this list have.

If it is going to be called SIP, then all entities must at least follow some basic SIP compatibility rules. I assume also that SIP methods and headers that normally operate between user agents will still operate between user agents. It should only be protocol that is currently impacted by stuff in the middle that should in any way be impacted by the scope of this work.

So maybe can I propose that SIP p2p supports all SIP methods and headers that normally operate only on a UA to UA basis. If we agree that, then we automatically support 90% of all the SIP RFCs that exist out there, including presence, IM and video. 

P2P SIP should only impact the protocol elements that deal with making sure that end-to-end stuff happens.

Thus while I might expect that something like Path or Service-Route will not work, or anything based on "trust domains", I would like to be confident that something like SUBSCRIBE or Replaces does.

If people really want to build something that doesn't do that, then surely you need to change the title of the list, as it is no longer SIP - and we will see where the IETF stand in terms of inventing a totally new VOIP protocol.

Remember, in Vancouver, I believe we were trying to address something that could be done by an IETF group, the discussion I have seen over the last few days seems to be determined to consign all the work to IRTF.

regards

Keith

> -----Original Message-----
> From: p2p-sip-bounces at cs.columbia.edu
> [mailto:p2p-sip-bounces at cs.columbia.edu]On Behalf Of Eunsoo Shim
> Sent: 11 January 2006 18:42
> To: henry at pulver.com
> Cc: p2p-sip at cs.columbia.edu
> Subject: Re: [p2p-sip] Requirements Explosion
> 
> 
> Henry Sinnreich wrote:
> 
> >>for basic audio-only no-NAT 
> >>SIP user agent
> >>    
> >>
> >
> >I hope we include presence and IM right from the start and 
> see no difference
> >if video will be there as well.
> >
> >  
> >
> I believe, once we have a design to support audio-only SIP 
> user agents 
> following the external DHT approach (or DHT-based approach), 
> it will be 
> fairly straightforward to support presence, IM and video in 
> that approach.
> So I support Henry's proposal with respect to setting our 
> very initial 
> design target.
> Thanks.
> 
> Eunsoo
> 
> >Thanks, Henry 
> >
> >-----Original Message-----
> >From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] 
> >Sent: Wednesday, January 11, 2006 9:09 AM
> >To: Kundan Singh
> >Cc: p2p-sip at cs.columbia.edu
> >Subject: Re: [p2p-sip] Requirements Explosion
> >
> >
> >  
> >
> >>So in conclusion, I think we should start with defining the generic 
> >>location-service and P2P-service protocol, and then 
> specific data format 
> >>for SIP-location-service, and implement it for basic 
> audio-only no-NAT 
> >>SIP user agent and basic SIP proxy and registrar using some 
> existing 
> >>DHT/P2P algorithm.
> >> 
> >>
> >>    
> >>
> >I like this proposal a lot like many other people.
> >Regards,
> >
> >Eunsoo
> >
> >
> >  
> >
> 
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>

---

From: henry at pulver.com (Henry Sinnreich)
Date: Wed, 11 Jan 2006 14:38:11 -0600

I am pleased to share there is a nifty public P2P SIP service out there:

http://damaka.com/download.htm 

It is a pretty rich product that works apparently both P2P and CS SIP, has
presence, IM, voice, video, lots of nice applications and NAT traversal
without any network servers.

This group is best qualified to give Damaka a hearty welcome!

Thanks, Henry

---

From: lists at bulukucing.org (Benny Prijono)
Date: Wed, 11 Jan 2006 22:56:54 +0000

> This group is best qualified to give Damaka a hearty welcome!

Henry,

Is it really "public" and "p2p SIP" as you claimed?

I just downloaded and tried the client, and it seems that you can only 
call (or be called by, maybe) people in the same damaka network. 
Hardly "public" by average definitions, and surprisingly matches 
perfectly the definition of "walled garden", which we love to discuss.

I listened to a podcast, they say the way it works is:

"the client contacts the (central) server to get the address of the 
buddies, then the client call the buddy directly without going through 
any server".

That doesn't seem like p2p that we discuss in this list. Maybe someone 
would clarify. It will be great to have more details.

-benny

---

From: huang-ming.pan at comcast.net (PP)
Date: Thu, 12 Jan 2006 08:32:59 -0800

"That doesn't seem like p2p that we discuss in this list."

With my limited knowledge and experience, I think, in no case, a client can
just be installed, boot up and immediately locate its buddies, without
looking up some sort of central server (eg. for address of at least one
super node), unless the client assumes "flooding" search approach, can it?

Peter
----- Original Message -----
From: "Benny Prijono" <lists at bulukucing.org>
To: <henry at pulver.com>
Cc: <p2p-sip at cs.columbia.edu>; "'Siva Ravikumar'" <siva at damaka.net>;
<satish at damaka.net>
Sent: Wednesday, January 11, 2006 2:56 PM
Subject: Re: [p2p-sip] Public P2P SIP service: Damaka.com

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Thu, 12 Jan 2006 11:44:24 -0500

It's also a not-so-subtle kick in the pants for all of us to get moving and
produce something before we become irrelevant.

Thanks, Henry.

--
Michael Slavitch
Ottawa, Ontario Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060112/714a90e5/attachment.html

---

From: lists at bulukucing.org (Benny Prijono)
Date: Thu, 12 Jan 2006 17:24:03 +0000

> super node), unless the client assumes "flooding" search approach, can it?

I wouldn't say it's impossible; in fact that's one of the key problem 
that P2P SIP would like to address, i.e. to remove the requirement of 
having one central server.

draft-bryan-sipping-p2p-01.txt talks about several ways to bootstrap 
the client:

1. to contact list of "well known" supernodes.
2. to contact cached address of my buddies, if I already have buddies.
3. or to "flood" (multicast, or whatever).

Option 2 is pretty good actually. Today, if I start up my Yahoo 
Messenger, I *always* have one or more buddies online, no matter what 
the time is. So I would say that if you have >70 buddies, there is a 
good chance that you'll be able to bootstrap your P2P client by 
contacting the buddies at their cached address.

When you're installing the client for the first time, the P2P service 
provider may preconfigure the client with "virtual buddies" (e.g. 
"London Echo server", "NY Echo Server"), so that the client can 
bootstrap with Option 2 above. Or with list of supernodes, for 
bootstrapping with Option 1.

But still the very idea of P2P is there shouldn't be a central server.

-benny

---

From: huang-ming.pan at comcast.net (PP)
Date: Thu, 12 Jan 2006 09:33:33 -0800

> 1. to contact list of "well known" supernodes.

Isn't this some sort of centralization? How many pre-known super nodes to
configure in all uniformly downloaded soft clients or manufactured hard
clients?

> 2. to contact cached address of my buddies, if I already have buddies.

Where did the "cached" address come from for a client that is launched the
very first time?

> 3. or to "flood" (multicast, or whatever).

How to multicast on WAN without blindly flooding the Internet?

Peter
----- Original Message -----
From: "Benny Prijono" <lists at bulukucing.org>
To: "PP" <huang-ming.pan at comcast.net>
Cc: <henry at pulver.com>; <p2p-sip at cs.columbia.edu>; "'Siva Ravikumar'"
<siva at damaka.net>; <satish at damaka.net>
Sent: Thursday, January 12, 2006 9:24 AM
Subject: Re: [p2p-sip] Public P2P SIP service: Damaka.com

---

From: henry at pulver.com (Henry Sinnreich)
Date: Thu, 12 Jan 2006 11:53:47 -0600

>the key problem that P2P SIP would like to address, i.e. 
>to remove the requirement of having one central server.

It is not the cost of the servers and all the other useless VoIP
infrastructure (SBC, softswitch, media server, component servers, QoS
network gear, MPLS, QoS monitoring, policy servers, etc.) but the cost of
the operations payroll for 7x24 staffing, plus manager, plus director, plus
VP, plus politics,...

VoIP operations payroll + complexity of VoIP infrastructure = get broke.

The self organizing property of P2P is nothing short of a revolution in
communication services. Besides the better resiliency, control in the
endpoint, getting rid of all the legacy telecom fetishes, etc., etc.

Thanks, Henry

-----Original Message-----
From: Benny Prijono [mailto:lists at bulukucing.org] 
Sent: Thursday, January 12, 2006 11:24 AM
To: PP
Cc: henry at pulver.com; p2p-sip at cs.columbia.edu; 'Siva Ravikumar';
satish at damaka.net

-benny

---

From: lists at bulukucing.org (Benny Prijono)
Date: Thu, 12 Jan 2006 18:05:02 +0000

Peter,

PP wrote:
> Isn't this some sort of centralization? 

To some degree, maybe yes. And I don't think it's possible to have a 
completely distributed P2P network without supernodes (taking into 
account NAT traversal). So yes, this is some sort of centralization to 
some degree.

But there is still a big difference between having several supernodes 
and *one* central logical server. It is this *one* central server that 
we don't want to have in P2P SIP.

> How many pre-known super nodes to

Well, I don't know. And I don't quite catch what you meant I'm 
affraid. I guess the answer is "enough", to guarantee that clients can 
bootstrap.

> Where did the "cached" address come from for a client that is launched the

That wouldn't be possible, of course.
But like I said, if you're a service provider, you can do a trick by 
putting virtual buddies (just like "Echo Server" in Skype) 
preconfigured in the client, so that the client can bootstrap.

> How to multicast on WAN without blindly flooding the Internet?

I trully don't know..
But it may still be a valid options to try, when else fail. Who knows 
may be somebody else in my office is using the same SIP P2P network.

-benny

---

From: huang-ming.pan at comcast.net (PP)
Date: Thu, 12 Jan 2006 10:32:05 -0800

Benny,

Thanks for the comments.

> we don't want to have in P2P SIP.

As i know, in current C/S deployments such as Vonage, SunRocket, and
Net2Phone, "one single central server" approach never happen. Clients are
provisioned with a long list of proxies/registrars for redundancy and load
balance. However, their "fewer" provisioning serverS seem more like
"centralized" stuff then.

Anyway I'm here all for p2p not for c/s. Just don't know, at least not yet
seen here, that an approach without any centralized stuff can be possible
for commercial practices, from download/manufacture, bootstrapping, the
first call routing to later on maintaining a usable DHT finger table without
assistance of some "centralized" stuff.

Even Skype has one sort of centralization -- signup servers which all Skype
clients must contact at least once during their life time and signin servers
which any Skype clients must contact every time when it boots up. I must
admire Skype engineers who seem sophisticated in provisioning and operating
a strong secure VoIP network both in design phase and operation phase --
even it is not 100% p2p.

Maybe a short-term goal here can be a network that has everything Skype
currently has but just replaces its call signaling protocol with SIP. At
least, one network should come out quickly with no less sophistication than
Skype has.

peter
----- Original Message -----
Sent: Thursday, January 12, 2006 10:05 AM

---

From: lists at bulukucing.org (Benny Prijono)
Date: Thu, 12 Jan 2006 18:46:12 +0000

> "centralized" stuff then.

That's why I said *logical* server, not just "server" ;)

(although to be fair, I missed the "logical" word in the second 
sentence).

I might as well have chosen a completely wrong word for that.

-benny