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

From: royrr at us.saic.com (Roy, Radhika R.)
Date: Mon, 23 Jan 2006 11:31:23 -0500

David:

I understand your point.

However, I think that the general principles for the p2p-SIP protocol will
be as follows:

1.      Base protocol will assume that all peers are equally capable. 
2.      If all peers are NOT equally capable, let us see which
functionalities need to be available as a common denominator from p2p point
of view. Then the separate protocol/service mechanisms need to be define for
any functions that are not available in any peers (an analogy of this can be
SIP Registrar, SIP proxy, SIP Redirect server functionalities that were NOT
a part of SIP UA capabilities). However, these mechanisms still need to obey
the principles of the p2p protocol.

Kindly see more inline [RRR].

Best regards,

Radhika

-----Original Message-----
From: davidbryan at gmail.com [mailto:davidbryan at gmail.com
<mailto:davidbryan at gmail.com> ] On Behalf Of David A. Bryan
Sent: Monday, January 23, 2006 9:16 AM
To: Roy, Radhika R.
Cc: PP; P2P-SIP
Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG

I don't think I agree it is clear the all features for all nodes

behavior is what we want, or that it is an issue that can be assumed

desirable until we see need for different behaviors. I think it is

open until we are clear what the services of a node are. For example,

I don't think that is true if we have TURN type media relay as a

service.

[RRR] Kindly see the points that have been made as stated above. I believe
that we can meet this requirement as well if we follow the above approach.

I guess I had two points in my earlier email:

1) If we decide we want all nodes always equal it would need to be

somehow explicit in the design, or in the end devices won't implement

them all. If for example, we design a basic protocol for resource

location and signalling, and one of those resource's a node can

advertise is it is willing to be a media relay (this could be one way

that nodes are defined as "slim" or "not slim" to use PP's terms),

there is no way to enforce which nodes advertise they have the service

and which don't. Any service we do decide should always be implemented

must be part of the protocol. If we wanted relay, we would need to

make it discovered in the protocol, not just advertised.

[RRR] Agree, but still we need to be careful that the p2p protocol
properties are maintained.

2) My second point was I can already see some cases -- the corporate

deployments I mentioned in the last email being one -- where they may

wish to control services like media relay. For managed deployments

where P2P is a way for an organization to reduce capex and opex, as

opposed to the Skype type-deployment, having different node types may

be desirable.

[RRR] Let us focus on p2p Public Internet first. Then, let us NOT worry now
how we can meet the requirements of the limited view of the p2p-corporate
schemes (it may be some especial cases or sub-sets of the p2p-public
Internet). By the way, no matter we do in the IETF, the corporate folks will
find their ways how to protect their interests (they may even create some
forums to make some special standards).

If we ignore it at this stage, we in effect decide implicitly by what

we design. For me it isn't obvious yet that making every node have all

capabilities is desirable for all the use cases I have seen. I think

that both types of uses (managed/unmanaged) are interesting and should

be kept in mind.

[RRR] As clarified above, let us develop the base p2p-SIP protocol first
with minimum common functionalities of all peers as indicated above. Then we
will have to step back to see what other things that we need to do to make
it real if anything is missing. Probably, we have to go forward step-by-step
(may be a learning curve). My proposal will be as follows: Not to make the
base p2p-SIP protocol a handicap just thinking some limited special
implementations.

--David

On 1/22/06, Roy, Radhika R. <royrr at us.saic.com> wrote:

> David and PP:

> Let me interject into this discussion.

> If we take the example of P2P-SIP, we see that this protocol will not

> distinguish between UA and proxy as every peer will have all the

> capabilities and may be termed as "peer Node" (instead of super-node,

> slim-node, etc.).

> So, the idea of the p2p-SIP protocol development will be how a peer-node
can

> satisfy the needs for p2p communications without being subordinate of
other

> nodes.

> In the past, we have seen simple dump device like POTS in the PEST world,

> client and sever communications protocol in the IP network, UA and Proxy

> entities in the case of non-p2p-SIP protocol, and others.

> As you have seen that we are now taking the approach of the path to make
SIP

> protocol completely P2P. Definitely, it will have more functionalities as
no

> peer wants to be subordinate compare to others.

> Consequently, we have to develop the basic protocol that works as p2p-SIP

> without assuming that some peer nodes will have super-node capabilities
and

> some are not.

> Once we develop the basic structure of the p2p-SIP protocol, we may then
see

> whether some kinds of hierarchical architecture of p2p configurations are

> necessary or not, but definitely we MUST not bog down to this right now.

> Any comments?

> Best regards,

> Radhika

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060123/141d61a6/attachment.html