Subject: [p2p-sip] Draft charter for possible P2PSIP WG

From: royrr at us.saic.com (Roy, Radhika R.)
Date: Sun, 22 Jan 2006 10:13:06 -0500

David:
 
If I understand correctly, it appears that P2P-SIP protocol itself will be
such that it will assume all functionalities will be available in each peer
(e.g., node, supernode, client-server node) without distinguishing between
UA and proxy.
 
In this way, it simplifies the protocol development because all peers are
equally capable.
 
So, the suggestion is this: Let us not differentiate by saying node,
supernode, or client-server node or otherwise. Let us call it simply a
"P2P-SIP Node" from P2P-SIP protocol point of view.
 
Best regards,
Radhika

  _____  

From: p2p-sip-bounces at cs.columbia.edu on behalf of David Barrett
Sent: Sat 1/21/2006 9:59 PM
To: 'PP'; 'Pyda Srisuresh'; 'Philip Matthews'; 'Dean Willis'
Cc: 'P2P-SIP'
Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG

> -----Original Message-----
> From: PP [mailto:huang-ming.pan at comcast.net
<mailto:huang-ming.pan at comcast.net> ]
>
> It sounds that the terms "clients" and "supernode" referred to two
> different types (implementations/functionalities) of p2p-sip nodes.

"client" and "supernode" functionality is certainly different.  It's
possible that a single node is able to do one, the other, or both.  The
ideal P2P deployment would have every node capable of performing both roles,
and some algorithm exists for promoting normal nodes into supernodes as
befits the network.

Today's SIP has "supernode" functionality firmly in the realm of the proxy,
and "client" functionality firmly in the user agent.  However, there's no
reason to prevent a user agent from behaving like a proxy.  But then again,
there's no reason to mandate that it do so, either.  The protocol should
support both, and then leave it up to the programmer to decide how far a
given node will go.

> Q1: how to know in advance during software build/release or hardware
> manufacture phase that a node will be running as "a client only" or as a
> supernode?

Ideally, any node that can act as both should act as both.  However, not all
nodes *can* implement both functions.  For example, some very trim device
might not have the computational resources to act as a supernode, but should
still be capable of acting as a normal client.

>
> Q2: when a node (soft or hard phone) is "made" to be working specifically
> as
> a supernode, won't the scenario become another flavor of client/server
> deployment?

Yes, just as an implementer should have the option of making a pure client,
he should have the option of making a pure server.  But again, the protocol
should allow a single node to act in either or both supernode and client
capacities.

Does this answer your questions?

-david

_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
<https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip>