RE: [Sipping] RE: Comments on draft-johnston-sipping-p2p-ipcom-01.txt

Xiaotao Wu <xiaotaow@cs.columbia.edu> Tue, 29 March 2005 16:25 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20622 for <sipping-web-archive@ietf.org>; Tue, 29 Mar 2005 11:25:18 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGJda-0003xS-Cl for sipping-web-archive@ietf.org; Tue, 29 Mar 2005 11:32:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGJRt-0003ZL-VV; Tue, 29 Mar 2005 11:20:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGJRr-0003Z7-Ot for sipping@megatron.ietf.org; Tue, 29 Mar 2005 11:20:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18766 for <sipping@ietf.org>; Tue, 29 Mar 2005 11:20:09 -0500 (EST)
Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGJYZ-0003I3-CM for sipping@ietf.org; Tue, 29 Mar 2005 11:27:09 -0500
Received: from flame.cs.columbia.edu (flame.cs.columbia.edu [128.59.16.145]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j2TGK3qt023050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Mar 2005 11:20:04 -0500 (EST)
Received: from flame.cs.columbia.edu (localhost [127.0.0.1]) by flame.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j2TGK3XT004082; Tue, 29 Mar 2005 11:20:03 -0500 (EST)
Received: from localhost (xiaotaow@localhost) by flame.cs.columbia.edu (8.12.10/8.12.10/Submit) with ESMTP id j2TGK2nQ004079; Tue, 29 Mar 2005 11:20:03 -0500 (EST)
X-Authentication-Warning: flame.cs.columbia.edu: xiaotaow owned process doing -bs
Date: Tue, 29 Mar 2005 11:20:02 -0500
From: Xiaotao Wu <xiaotaow@cs.columbia.edu>
To: Brian Rosen <br@brianrosen.net>
Subject: RE: [Sipping] RE: Comments on draft-johnston-sipping-p2p-ipcom-01.txt
In-Reply-To: <200503291609.j2TG9jqt020973@cs.columbia.edu>
Message-ID: <Pine.GSO.4.58.0503291112130.19328@flame.cs.columbia.edu>
References: <200503291609.j2TG9jqt020973@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Cc: "'Johnston, Alan'" <alan.johnston@mci.com>, 'sipping' <sipping@ietf.org>
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6

On Tue, 29 Mar 2005, Brian Rosen wrote:

> I think this is not true.  All you need is multiple contacts with q values
> so that eventually, one endpoint gets the call; voicemail in this case.

This can be done through caller preference, and as you said, use q values,
no CPL scripts needed.

>
> Forwarding can also be done if an endpoint is allowed to forward.  The
> endpoint has to be trusted by the user, but that's the nature of p2p.

Users may trust nodes for routing, but should users also trust nodes for
not releasing privacy? For example, if you use time-switch for time-based
call routing, your schedule can get released. If you have call screening
service to block a people you don't like, can you ensure that that
people's node will not be one of the routing nodes?

Certainly, it works in most cases if you put your scripts to whatever
nodes in the network, e.g., by using REGISTER, but leave it in your
endpoints are better.

-Xiaotao

> I imagine that what happens really is that I have an endpoint which is mine,
> and under my control that is last in the contact list.  It has CPL, or
> whatever I want, and forwards the call if necessary.
>
> Brian
>
> > -----Original Message-----
> > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf
> > Of Xiaotao Wu
> > Sent: Tuesday, March 29, 2005 10:58 AM
> > To: Arjun Roychowdhury
> > Cc: Johnston, Alan; sipping
> > Subject: Re: [Sipping] RE: Comments on draft-johnston-sipping-p2p-ipcom-
> > 01.txt
> >
> > > > >     return more than just a simple Contact URI. In a pure Peer-to-
> > peer
> > > > >     SIP network, if the user's phone is not reachable (e.g., it is a
> > > > >     wireless phone that is out of range), then we would still like
> > > > >     the call to follow the user's call handling preferences.
> > > > > This might
> > > > >     involve taking voicemail for the user, or forwarding the call to
> > > > >     another AoR. The user might have expressed these call handling
> > > > >     preferences by uploading a CPL script to the "network" somehow
> > > > >     beforehand.
> > > >
> > > > Yes - these are important requirements that we will want to meet with
> > > > this protocol.
> > >
> > > Why is this an important requirement ? If the goal of this draft is
> > > pure p2p, then there is no intelligent network inbetween that needs to
> > > be relied on from a service perspective. If CPL needs to be invoked,
> > > it would be a part of the User Agent either originating or terminating
> > > a call and not some node in between.
> >
> > I agree with Arjun's point. In a P2P network, you cannot put your
> > service scripts in the network due to both reliability and privacy
> > concerns. If you want it to be reliable, you must have your scripts
> > distributed to all potential routing nodes, which you never know whether
> > they are trustable or untrustable, and the privacy will be a big concern.
> >
> > There could be some exceptions, such as spam filtering, a user may like to
> > push it into the network so he does not have to keep a copy for all his
> > devices. But, keeping service script copies on every device and
> > synchronize the copies would not be a big problem in a P2P network.
> >
> > For services on endpoints, we have extended CPL to the Language for End
> > System Services (LESS), which can be found at
> >
> > http://www.ietf.org/internet-drafts/draft-wu-iptel-less-00.txt
> >
> > The new language removes the 'proxy' action in CPL since you would not
> > expect your endpoints to proxy calls. The language will just fit the P2P
> > environment for services.
> >
> > Thanks!
> >
> > -Xiaotao
> >
> > >
> > > --
> > > Arjun Roychowdhury
> > >
> > > _______________________________________________
> > > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sip@ietf.org for new developments of core SIP
> > >
> >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> >
>
>
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP